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SECTION  1 
INTRODUCTION 


sssEE  at  mi  eamtci 


This  project  was  Initiated  originally  os  a  broad-based 
examination  of  the  problems  and  difficulties  encountered  In 
transporting  very  large  COBOL  programming  systems  and  the 
development  of  tools  that  would  assist  In  such  activities* 
As  the  project  progressed*  It  became  apparent  that  there 
were  a  number  of  other  Issues  that  should  be  addressed*  such 
as  the  maintenance  of  t r anspor t able  programs  as  well  as  the 
aulek  development  of  breadboard  programs  to  examine  specific 
concepts*  These  concepts  have  been  Integrated  Into  the 
original  project  and  this  report  covers  the  most  Important 
output  of  this  oroject*  the  COBOL  Programmer’s  workbench 
which  Is  the  collection  of  tools  and  other  supportlno 
software  for  the  design*  Implementation*  and  maintenance  of 
baseline  programs  that  can  be  easily  transported  to  a  wide 
variety  of  target  operatlno  environments  as  well  as  for  the 
support  of  the  quick  development  of  breadboard  programs* 
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i.i.i  fiaiii 

The  specific  goals  established  Tor  the  final  portion  of  this 
project  were: 

1)  "<osine  the  problems  involved  in  establishing 
a  baseline  program  that  could  be  easily 
transported  to  a  wide  variety  of  target 
operating  env 1 ronrent s. 

?}  'stablish  techniques  for  the  design  and  Im¬ 
plementation  of  such  baseline  programs 
utilising  the  isrti  1nu»  assistance  possible 
from  automated  software  programming  aids. 

1)  -'Cvelop  a  plan  for  the  maintenance  of  the 
system  docunent at  1  on  required  for  suoport  of 
the  programs  as  well  as  user  documents. 

«>  ‘  »aainc  the  fcasaoility  of  integrating  all  of 

these  toots  into  a  single  programmer  support 
env 1 ron*cn t • 


i.i.2  u&fliallitinpli 


The  oroject  has  been  successful  in  accomplishing 
specific  goals  sot  out  at  the  beainning. 

1)  The  concept  of  being  able  to  develop  a  single 
baseline  program  that  can  automat ically  be 
transoorted  to  various  operating  target  en¬ 
vironments  has  oeen  successfully 

demonstrated. 

?)  The  preliminary  cha rac t er  1  s 1 1 c s  for  the  COBOL 


the 
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orograw*er» s  environment  have  been 

established* 

3)  Alt  of  the  software  aids  have  been  Integrated 
Into  s  single  operating  environment  known  as 
the  COBOL  Programmer's  Workbench. 

i*i*s  QraiPlulJUm  ai  ifali  fiiaarl 

Following  this  Introductory  section*  which  establishes  the 
envlronnent  applying  to  the  need  ano  value  of  transportable 
baseline  programs*  Section  ?  presents  an  overview  of  the 
facilities  and  capabilities  thot  would  be  provided  by  a  cor- 
plete  COBOL  Programme^* s  Workbench.  Section  3  describes  the 
functional  components  that  constitute  the  Workbench.  Sec¬ 
tion  s  clscusses  how  the  Workbench  would  be  utilized  to  ac¬ 
complish  the  various  tasks  required  during  the  design*  1 » - 
plementat Ion*  and  maintenance  of  large  programs  and  systems. 
Section  S  oresents  some  details  on  the  Implementation  of  the 
demonstration  version  of  the  COBOL  Programmer’s  Workbench 
that  was  Implemented  at  the  Georgia  Institute  of  Technology. 
Following  a  summary  section*  the  appenolces  provide  more 
detail  on  toolcs  such  as  Workbench  COBOL  (the  transportable 
subset  of  the  language)*  techniques  for  document  control*  a 
description  of  the  major  components  of  the  Georgia  Tech 
Software  Toots  Subsystem  which  was  utilized  extensively  In 
the  Implementation  of  the  Workbench*  a  glossary*  and*  per¬ 
haps  of  most  Interest*  an  annotated  example  of  the  operation 
of  the  Demonstration  Workbench* 
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i«2  mmims.  m  m  tmk 

There  .-.-re  a  numoer  of  objectives  r.odlvating  the  design  and 
iaolenentdtlon  of  a  facility  such  as  the  COBOL  Programmer** 
Vorl bench.  A  few  of  these  are  outlined  below! 

1)  deduce  cost  and  Increase  p rodyc t 1 v 1 t y • 

2)  Avoid  reprogramming. 

i)  Support  the  multiple  use  of  program 
nodules. 

0)  Reduce  the  problems  of  system 
sa Intenance. 

c)  Support  S.Hil  t  ranspor  t  at  Ion  of  a  large 
program  to  a  number  of  operating  en¬ 
vironments  without  requiring  reprogram- 
*  1  no  . 

3)  Maintain  control  of  the  baseline  program, 
i)  Code. 

t>)  Document  at  Ion. 

*)  Support  the  quick  and  low-cost  development  of 
breadboard  systems  that  will  allow  the 
domination  of  a  system  or  program  concept 
without  Incurring  the  full  cost  of  comolete 
development. 
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1.3  flgEBAJUMfi  EMXlBBMflCai  ftf.  UtlttUX 

Although  almost  any  programming  environment  would  benefit 
from  th?  Ideal  and  facilities  that  are  Incorporated  Into  the 
COBOL  Programmer*!  Workbench,  tne  research  on  the  Workbench 
was  focused  primarily  on  an  environment  having  the  following 
characteristics. 

1)  A  single  organization  Is  responsible  for  the 
deslon.  Implementation*  and  maintenance  of  a 
large  number  of  data  processing  systems. 

2)  The  data  processing  systems  are  written  In 
COBOL. 

3>  THr  systems  are  quite  large,  usually  consist¬ 
ing  of  more  than  100.000  COBOL  statement*  ana 
often  much  larger. 

a)  The  data  processing  systems  have  a  long 

lifetime  -  five  to  eight  years  -  and  they 
must  be  maintained  by  the  preparing  organiza¬ 
tion  throughout  their  entire  lifetime. 

5)  The  personnel  In  the  maintenance  oroup  of  the 
programming  organization  may  work  on  more 


than 

one  system. 

6 ) 

The 

Indiv Idual s 

that  develop 

the 

system 

are 

not 

necessarily 

aval lable 

for 

for 

Its 

maintenance!  most  often,  they  will  not  be 
aval lable. 

7)  The  data  processing  systems  will  be  executed 
on  a  variety  of  hardware  conf Iguratlons  which 
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nay  not  utilize  COBOL  systems  identical  to 
that  utilized  by  the  development  agency. 

8)  The  oesign  cycle  for  a  new  system  or  a  major 
modification  to  an  existing  system  is  e»* 
tremely  long  and  costly. 

9)  The  time  pressures  Involved  for  the  delivery 
of  a  new  system  usually  preclude  being  able 
to  produce  a  trial  design. 

Moure  1.3-1  illustrates  the  meanings  of  the  terms  used  In 
this  report  to  describe  the  various  programs  existing  in  the 
operating  environment  ---  P.CLCASCS*  VCRSIQhS*  and 
MODIFICATIONS. 

nuUlakt  Lmmiao  fcaulttniioii 

An  extremely  Important  characteristic  of  the  environment 
projected  for  the  utilization  of  the  COBOL  Programmer's 
vorvccnch  is  the  reoulreocnt  that  the  COBOL  data  proccsslnc 
syst  develoocd  be  capable  of  being  executed  on  a  "wide" 

variety  of  computer  systems.  The  variety  of  execution  en¬ 
vironments  say  Include  totally  different  systems  supplied  by 
different  hardware  manufacturers  as  well  as  variations  In 
the  operating  systems  under  which  Identical  hardware  systems 
say  be  executing.  The  different  environments  may  also  ex¬ 
hibit  large  variations  In  the  operational  load  placed  on  the 
execution  system  since  the  total  processing  loads  may  be 
quite  different. 
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knowledge*  Inf ormat Ion*  and  understanding  required  to 
transport  a  orogram  exceeds  even  that  required  to  maintain 
the  oroorae.  (We  at  Georgia  Tech  did  not  consider  our 
transporting  activity  to  be  totally  successful*  however*  the 
knowledge  that  we  gained  about  the  problems  of  transporting 
progross  was  extremely  valuable*) 

There  Is  no  avoiding  the  fact  that  transporting  la  rue  COBOL 
programs  fro*  one  operating  environment  to  another  Is  an  ex- 
t  remely  costly  and  time  consu*1ng  activity.  There  are  two 
approaches  to  this  proble*  and  Doth  have  applicability  to 
specific  Instances. 

The  first  approach  night  be  characterljsed  as  a  linear  tech¬ 
nique.  The  program  Is  originally  written  on  machine  A  to 
run  only  on  that  system.  Then*  as  the  need  arises*  the 
program  Is  transported  fro*  fiachlne  A  to  machine  R*  and* 
then*  later  fro*  machine  8  to  nachlne  C  and  so  on.  If  there 
Is  only  a  single  operating  env1ron«cnt  required  at  any  one 
t1*e  and  If  the  machine  conversions  do  not  occur  too 
f  requent ly«  then  the  linear  approach  to  transporting  the 
programs  Is  probably  the  best  and  cheapest  since  the  only 
problems  that  «us  t  be  addressed  arc  those  arising  directly 
froe  the  1nco*patob1  llty  of  the  jifo  *ach1nes  Involved. 

The  other  approach  to  transporting  programs  can  be  charac¬ 
terized  as  the  "star  technique."  The  proqra*  Is  originally 
written  In  a  language  applicable  to  the  development  machine. 

Georgia  Institute  of  Technology  COBOL  Workbench 


Section  1 


INTRODUCTION 


Page  10 


This  program  then  become*  the  baseline  program  which  1* 
controlled  to  Insure  that  the  program  continues  to  meet  the 
operating  requirements  of  the  system.  In  this  environment* 
whenever  a  new  target  operating  environment  Is  required*  the 
program  Is  transported  from  the  central  development  machine 
directly  to  the  target  environment.  It  should  be  recognized 
that  In  this  environment*  the  initial  cost  of  developing  n 
program  on  the  central  machine  that  can  be  transported  to  a 
wine  variety  of  target  operating  environments  without  any 
re.tcslon  Is  higher  than  the  cost  for  developing  a  program  on 
j  single  machine  that  will  then  later  be  transported  to  only 
another  single  machine. 
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SECTION  2 

CAPABILITIES  OF  THE  COBOL  RROGRANHER*$  WORKBENCH 


2.x  &uujuk  amna 


The  primary  goal  of  the  COBOL  Prog reamer  *  *  Workbench  1*  to 
assist  and  support  the  development  of  COBOL  programs  in  an 
efficient*  cost  effective*  and  speedy  manner.  This  goal  is 
to  be  accomplished  by  the  development  of  an  integrated  en¬ 
vironment  of  powerful  software  tools  easily  accessible  and 
usable  by  th<*  programmer.  The  general  objective  is  to  make 
maximum  use  of  the  data  processing  capabilities  of  the  Work¬ 
bench  in  order  to  increase  the  productivity  of  the  COBOL 
programmer « 


The  COBOL  Workbench  provides  a  wide  variety  of  capabilities 
to  the  systems  analyst  and  programming  staff.  As  can  be 
seen  fro*  the  list,  of  these  capabilities  given  in  Table  2.1- 
1*  it  1$  envisioned  that  automation  support  be  provided  for 
all  phases  of  program  development*  maintenance*  and 
document  at  ion. 


The  central  concept  of  the  programming  subsystem  is  the 
preparation  of  a  baseline  program  that  can  be  easily  and  ac¬ 
curately  transported  to  a  large  variety  of  target  operating 
environments.  The  baseline  program  is  written  and 
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maintained  In  "Workbench"  COBOL  and  Is  processed  by  one  of 
the  components  of  the  Workbench  to  produce  a  "coipUer- 
unloue  version*  of  the  baseline  program.  The  Workbench  also 
supoorts  the  testing  of  the  baseline  program.  It  will  also 
provide  some  assistance  In  the  testing  of  compl ler-unloue 
versions  of  the  baseline  program;  however*  It  Is  obvious 
that  the  final  testing  of  these  programs  must  be  done  on  the 
target  environment.  Both  the  baseline  RELEASES  ot  the 
program  as  well  as  Its  cemo  1 1 e r »un  1  que  VERSION'S  will  be 
maintained  on  the  Workbench.  The  principal  problem  here  Is 
not  so  much  one  of  programming  in  COBOL  as  It  Is  a  problem 
of  document  maintenance  and  control.  Therefore*  the  program 
salntenance  function  Is  almost  totally  supported  by  the 
capabilities  of  the  documentation  subsystems. 

The  document  at  Ion  subsystem  Is  designed  to  handle  both 
program  te*t  and  supporting  documentation.  The  preparation 
of  oroiraaj  Is  supported  by  the  programming  subsystem  while 
the  preparation  of  supporting  documentation  Is  supported  by 
the  documentation  sunsystem.  However*  both  of  these  types 
of  documents  fall  under  a  common  document  control  procedure. 
In  o  situation  where  proarams  are  under  continual 
maintenance  and  modification*  several  versions  of  both  the 
code  as  well  as  the  support  documentat Ion  must  be 
maintained.  It  It  the  function  of  document  control  to 
provide  progranmers  and  systems  analysts  with  the  ability  to 
recall  any  specific  versions  of  a  program  or  its  supporting 
documentation  that  they  wish  to  utilize.  The  documentation 
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subsystem  olso  provides  the  capabilities  needed  for  prcouc- 
Ing  final  documentation  In  a  format  suitable  for  publication 
anu  distribution. 

Another  Important  capability  of  the  Workbench  Is  the  ability 
to  produce  and  utilize  reusable  COBOL  Modules.  There  are  a 
number  of  COBOL  programming  support  system  In  existence 
that  facilitate  and  support  the  preparation  of  COBOL 
programs  In  modular  form  so  that  a  program  may  be  divided 
among  a  teao  of  programmers.  However,  those  systems  support 
the  preparation  of  modules  for  utilization  In  a  single > 
cpbp lie r-and-app Ileal lon-d«peQg«nl  COBOL  program,  in  other 
words,  the  final  use  and  the  detailed  specifications  of  each 
module  are  dictated  by  the  spec  1  Me  program  under  develop¬ 
ment.  The  goal  of  the  Workbench  Is  t©  give  programmers  thr 
ability  to  develoD  modules  that  can  be  used  In  several  dif¬ 
ferent  programs.  These  modules  will  have  "standard"  inter¬ 
faces  and  will  be  capable  of  being  parameterized  Internally 
to  match  the  specific  requirements  of  the  COBOL  proara*  un¬ 
der  development.  The  purpose  of  provldlncj  this  capaoillty 
Is  to  facilitate  the  rapid  and  lew-cost  preparation  of 
prototype  COBOL  systems  providing  a  specified  capability  and 
functionality  without  the  expense  and  time  reoulred  for  the 
design  of  a  completely  new  COBOL  system. 
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TABLE  2.1-1 

1 

1 

i 

1 

.« j|| 

capabilities 

OF  THE  COBOL  PROGPAHHER«S  WORKBENCH 

\ 

I 

1 

*1 

I*  Prograaaing  Subsystea 

1 

1 

1 

A  • 

Prograa  Preparation 

1 

i 

i 

1. 

Prograaaer*s  Environaent 

1 

• 

a.  Special  COBOL  Screen  Editor 

• 

\ 

b.  Standards  Enforceaent 

1 

c.  Library  Support 

1 

-  Prograa  Preparation  Skeletons 

1 

i 

-  Utilization  of  Reusable  Nodules 

1 

* 

2. 

Transportable  Baseline  Prograa 

1 

; 

a.  COBOL. wbc 

1 

3. 

Prograa  Processing 

1 

* 

a.  Expansion 

1 

b.  Library  Support 

! 

c.  Coapi ler-Unlque  VERSIONS 

1 

e. 

Prograa  Testing 

1 

1. 

Test  •Harnesses* 

1 

2. 

Test-Data  Generation 

1 

• 

3. 

Test  Libraries 

1 

c. 

Prograa  Haintenante 

! 

1. 

Inereaental  Changes 

1 

* 

2. 

Support  of  Multiple  RELEASES/VERSIONS 

1 

I  II.  Oocuaentat ion  Subsystea 

1 

A  • 

Oocuaent  preparation 

1 

1. 

0-1 g Inals 

1 

2. 

Updating 

1 

B. 

Oocuaent  Control 

1 

1. 

Support  Nultiple  RELEASES/ VERS  IONS 

1 

2. 

Audit  Trail  of  Changes 

1 

3. 

Linkage  of  Coaaents 

t 

C. 

Oocuaent  Production 

1 

1. 

Progress 

i 

2. 

Supporting  Docuaentat ion 

t 

1 

1 

1 
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2*2  mm&  lumum 


Program  preparation  1*  the  first  major  capability  provided 
by  the  Programming  Subsystem*  It  consist*  primarily  of  the 
capabilities  to  produce  the  Basellre  Program  RELEASE  ana  the 
Compiler-Unique  VERSIONS  of  that  RELEASE*  Thr  Programming 
Subsystem  also  provides  the  capability  for  Quickly  and 
easily  Implementing  a  "breadboard  design"  of  a  programming 
system  utilising  reusable  modules  and  other  facilities  of 
the  Workbench* 

2*2*i  flxiDtli*  al  Etiacii  frtatrftllflD 

One  ot  the  goals  of  the  Workbench  Is  to  provide  a  program¬ 
ming  environment  which  will  assist  the  programmer  throughout 
the  entire  development*  Implementation*  operation*  and 
maintenance  processes.  This  Implies  the  development  of  a 
number  of  software  tool*;  Another  goal  Is  l  he  concurrent 
development  of  programs  for  different  taroet  machines*  The 
approach  taken  In  the  Workbench  Is  to  write  In  an 
env  1  ronment- Independent  language*  Workbench  COBOL 
(CraOL.wbc)*  and  lo  convert  that  language  to  a  particular 
COBOL  dialect  only  when  preparing  the  delivery  of  the  com¬ 
plete  program  to  the  Installation  (see  Figure  2*2. 1-1).  A 
third  goal  Is  to  orovlde  the  capability  to  make  use  of 
reusable  code  modules  whenever  a  task  or  function  can  be 
Identified  that  Is  freauently  used. 
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2*2*2  Etmimin  Leutlcmitnl 

The  programmer**  environment  may  be  described  as  the  Inter¬ 
face  between  the  human  and  the  machine.  It  consists  of 
those  tools  which  are  provided  to  assist  directly  In  the 
task  of  preparing  code.  Depending  on  the  particular  system* 
the  programmer  may  be  faced  with  a  "hostile"  or  a 
■ fr lendly/hosp 1  table"  environment.  A  hostile  environment 
may  complicate  the  programming  task  In  many  ways:  primitive 
file  system*  restrictive  naming  conventions*  obscure  error 
messages*  etc.  A  system  may  alto  make  programming  difficult 
by  providing  the  programmer  with  only  a  few  tools  of  Umltea 
caoabl l 1 t let. 

The  Workbench  contains  a  number  of  very  powerful*  yet  easy 
to  use  software  tools  to  simplify  the  programmer**  task  and 
to  permit  a  more  efficient  Interface  between  the  human  and 
the  machine.  These  toots  Include  a  special  editor  for 
entering  COBOL  t  e*  t  •  a  standards  enforcer  to  verify  the 
clerical  correctness  of  code  before  further  processing* 
skeleton  proorams  to  aid  In  code  preparation*  trst  routines 
to  aid  In  the  test  process*  and  a  well-structured  file 
system  to  allow  all  of  these  to  work  together  efficiently 
and  productively. 
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2. 2.2, l  Special  COBOL  Editor 

The  purpose  of  the  special  editor  Is  to  assist  the  program¬ 
mer  In  the  entering*  ma In t enance «  and  updating  of  files 
containing  COBOL  code.  It  Is  designed  to  support  the 
Interactive  preparation  of  COBOL  code  utilizing  a  CAT 


B 


l; 


i 


i 


£ 


terminal. 

The  special  editor  should  have  the  following  capabilities: 

1)  Provide  the  programmer  the  capability  to 
enter  COGOL  code  easily. 

2)  Provide  the  capability  to  modify  or  extend 
existing  code  files. 

1)  CrQAnlye  and  display  the  code  entered  In  a 
standard  and  easy  to  read  format. 

•*)  Provide  the  ability  to  refer  to  code  by  line 
numbers  as  well  as  paragraph  names. 

5)  Provide  the  ability  to  recall  and  easily 
modify  modules  cf  code  such  as  file 

definitions  or  a  scries  of  almost  Identical 
repetitive  calculations. 


I 


£ 

I 


2. 2. 2. 2  Standard*  Enforcer 

The  purpose  of  the  standards  enforcer  is  to  verify  that  the 
orogranmer  has  adhered  to  the  COBOL. wbc  syntax*  names*  and 
f orna t  s  t anda  rds. 


m 


m 
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The  standard*  enforcer  must  check  that  the  following 
requirements  are  net: 

1>  Code  Is  written  In  a  machine-  and  compiler- 
unique  for*.  In  the  Workbench*  this  Is  ac¬ 
complished  by  verifying  that  all  statements 
are  acceptable  within  COBGL.wbe  syntax. 

2)  Naming  conventions  are  followed  correctly. 

*t  the  least*  It  Is  possible  to  determine 
that  a  variable  used  In  several  code  segments 
maintains  the  same  data  type  throughout  Its 
use  • 

3)  a  check  Is  made  for  clerical  errors*  such  as 
the  misspelling  of  reserved  words  or  of 
variable  name*.  Following  this*  the  code  Is 
processed  through  a  "pretty-print"  program  to 
guarantee  clerical  uniformity. 

2.2. 2. 3  Library  Support 

There  are  a  number  of  different  "libraries"  utilized  by  the 
workbench*  and  several  of  these  collections  of  flics  ray  be 
utilized  by  the  same  Workbench  activity.  a  complete  discus¬ 
sion  of  the  various  libraries  and  their  components  will  be 
olven  later  after  more  of  their  uses  have  been  covered.  As 
far  as  supporting  the  COBOL  Programmer’s  Environment  1* 
concerned*  It  should  be  obvious  that  some  of  the  files  that 
should  be  ovaltable  are 

1)  blocks  of  code  providing  definitions  of 
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characteristics  applicable  to  a  specific 
program  under  development  such  as  the  tile 
definition  statements* 

?)  Slocks  of  code  providing  a  iXiSCafiilK  i2£  the 
iCMii££E£Qi  a  special  or  tailored  version 
of  a  commonly  encountered  function  such  as 
the  File  Definitions*  an  edit  routine*  a 
repetitive  calculation*  etc* 

3)  Larger  olocks  of  code  that  are  treated  as 
"open  subroutines"  and  Inserted  In  the 
orogra*  under  development  as  In-line  code* 

*• )  etc. 

These  files  alqht  have  been  developed  by  a  programmer  for 
his  own  use  and  kept  In  his  private  or  Personal  Library*  or 
they  may  have  been  developed  for  wider  usage  and  placed  In 
the  General  Library  or  one  applicable  to  a  specific  applica¬ 
tion  area  or  project  under  development*  Since  simitar  files 
say  f*ist  In  all  of  these  various  libraries*  the  order  In 
which  they  are  searched  Is  very  Important.  This  topic  Is 
also  discussed  oelow. 

2*2. 2*3*1  Sliiiii&U  BaUulti 

An  enanolc  of  the  use  of  reusable  modules  may  be  seen  In  the 
very  large  class  of  problems  In  which  a  transaction  file  Is 
processed  against  a  caster  file  to  produce  a  report.  The 
mainline  processing  may  be  performed  by  the  following 
module  I 
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OPEN  INPUT  MASTEH-F ILE 
TRANS-FILE 
OUTPUT  REPORT-FILE 

PERFORM  PROCESS-TRANSACTIONS 
UNTIL  NO-MOPE  -  TRANS 

CLOSE  MASTER-FILE 
TRANS-FILE 

report-file. 

S TOp  RtJN. 

Once  this  nodule  of  code  1$  thoroughly  tested*  It  can  be 
copied  from  the  appropriate  library  for  use  without 
modification  in  stellar  program*.  Since  this  module  is 
logically  quite  staple  and  relatively  short,  it  may  appear 
easier  to  write  It  again  for  each  new  progr**.  than  to  expend 
the  additional  effort  required  to  check  out  the  code  and 
catalog  it  in  a  library.  The  major  advantage  of  considering 
this  short  program  segment  es  a  reusable  module  is  that 
these  nine  lines  of  code  can  be  Included  in  some  larger 
module  by  means  of  a  simple  macro  call.  Thus  many  errors, 
even  simple  typographical  ones,  are  avoided. 

Continuing  the  same  example,  other  reusable  nodules  may  be 
developed.  The  main-line  module  performs  a  paragraph 
PROCESS-TRANSACTIONS  which  is  invariant. 

The  nodule 

PROCESS-TRANSACTIONS. 

MOVE  *N0*  TO  VALID-TRANSACTION. 

PERFORM  GET-VALSD-TRANSACTION 
UNTIL  VALID-TRANS 
OR  NO-HORE-TRANS. 

IF  VALID-TRANS 

THEN  PERFORM  PREPARE-RESPONSE « 

will  call  the  reusable  module  GET-VALIO-TRANSACTION  and  con- 
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ditionally  call  the  module  which  will  actually  process  the 
transaction.  The  paragraph  PRCP ARE-RESPONSE  will  typically 
npt  he  in  the  form  of  it  reusable  module  since  each  applica¬ 
tion  program  using  this  general  model  will  have  different 
reoui rement s  for  the  processing  of  a  transaction. 


The  essential  feature  of  the  two  paragraphs  given  in  the 
example  above  is  that  they  apply  to  a  large  class  of  ap¬ 
plication  programs  and  therefore  may  serve  as  a  model  for 
the  development  of  reusable  nodules  tor  a  commonly 
encountered  class  of  proolers. 


Miil 


-'•2.2.J.2  2e aanac  Gc*ciaaaimi  lititliiii 

As  contrasteo  to  reusable  modules*  which  provide  the  com¬ 
plete  code  required  to  accomplish  a  specific  task  or 
automat ical ly  generate  such  code  after  suitable  parameters 
are  orovided  in  the  reference  to  the  module*  a  program 
development  skeleton  is  primarily  a  f ramework  and  ggi^y  for 
the  development  of  a  program  which  might  vary  ouite 
considerably  from  anything  that  has  been  developed 
previously.  A  orooram  deve l opment  skeleton  is  much  more 
generally  applicable  than  a  reusable  module.  An  example  of 
a  skeleton  Is  the  oartial  description  of  the  file  definition 
section  of  the  orogram  in  which  those  characteristics  which 
have  been  established  as  local  standards  for  the  programming 
organization  are  already  specified  and  the  skeleton  in¬ 
dicates  where  further  information  should  be  provided  by  the 
proorommer  utilizing  It  In  the  preparation  of  a  specific 
orocras.  There  can  also  be  program  development  skeletons 
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which  hand te  such  larger  tasks*  There  are  even  Instances  of 


skeletons  being  utilized  for  the  development  of  complete 


program  s • 


2*2*2* A  Use  of  Libraries 


Different  typos  of  modules  and  skeleton  programs  arc 


provided  on  different  libraries  to  permit  ease  of  reference 


an-j  to  prevent  Improper  access*  The  libraries  defined  are 


described  In  section  2*2*a*1  and  Include  libraries  for  the 


fol  lowing: 


1)  'eneral  purpose  modules* 


2)  Modules  for  a  specific  application  area* 


3)  Modules  under  development  for  a  particular 


project. 


a)  Programmer-developed  modules  for  personal 


5)  Test  nodules. 


6)  Compiler-unique  modules* 


2*2*3  imaiaartmt  fliitilni  fxaaim 


The  development  and  maintenance  of  a  coeplete  COBOL  program 


that  can  oe  easily  transported  to  «  large  number  of  tarprt 


computer  operating  environments  Is  certainly  one  of  the  most 


Important  produc ts  produced  by  the  COBOL  Programmer* s  Work¬ 


bench*  There  1$  certainly  a  large  monetary  value  that  can 


be  associated  with  the  other  capabilities  of  the  Workbench 


such  as  the  ability  to  quickly  develop  prototype  systems 
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utilizing  reusable  program  modules  and  the  machine  as¬ 
sistance  orovlded  In  the  development  and  production  of  sup¬ 
porting  documentat Ion.  However*  In  the  environments  ot 
Interest  In  this  study  <those  that  were  detailed  In  section 
1)  the  major  economic  payoff  appears  to  be  vested  In  the 
ability  to  produce  a  program  that  can  be  automatically 
transported  to  a  variety  of  target  computer  operatlno  en¬ 
vironments  without  extensive  human  Intervention  In  the 
transcortat  Ion  process.  This  t ranspor tat  Ion  capability  Is 
provided  primarily  through  the  utilization  of  Workbench 
COSOL  or  COSOL. woe  as  the  programming  language. 

2.2.4  Uftiifetmii  tflflflk 

The  concept  of  Workbench  COBOL  Is  certainly  one  of  the  most 
Important  central  Ideas  In  the  COBOL  Programmer’s  Workbench. 
The  objective  of  Workbench  COBOL  Is  to  provide  a  language 
the  croaranmer  may  v  to  prepare  programs  that  can  be 
easily  transported  to  a  variety  cf  target  environment 
systems.  *>  secondary  objective  of  Workbench  C080l  Is  to 
Include  facilities  for  the  use  of  reusable  COBOL  modules  and 
ether  program  productivity  aids.  There  have  been,  since  the 
verv  beginning  of  C080L.  a  number  of  demonstrations  of  the 
ability  to  transport  programs  from  one  system  to  another. 
This  has  been  reinforced  In  recent  years  by  the  establish¬ 
ment  of  national  standards  for  COBOL?  however.  It  Is  a  well 
recognized  fast  that  It  Is  ex t  rem*  y  difficult.  If  not  Im¬ 
possible.  to  execute  any  out  the  most  trivial  COBOL  programs 
on  different  systemc  without  making  some  changes  to  the 
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code.  Some  difference*  are  quite  obvious.  such  as  the 
situation  where  statements  required  by  one  compiler  must  be 
absent  In  another  or  prepared  In  quite  a  different  form. 
e.g.»  the  file  label  statement.  Other  problems  of 
t ransportat Ion  are  much  more  difficult  to  handle,  such  as 
the  effects  of  word  size  when  the  computational  form  for 
variables  Is  utilized.  It  Is  x  goal  of  the  design  of  work¬ 
bench  COBOL  to  overcome  all  of  these  difficulties. 


The  basic  objectives  In  the  design  of  the  Workbench  COBOL 
language  are  as  follows: 

1)  COBOL  «wbc  should  be  as  close  os  possible  to 

standard  COBOL  In  syntax  and  semantics.  This 
will  greatly  assist  In  the  training  of 

programmers  to  utilize  the  Workbench. 

2)  COBOL. wbr  should  be  capable  of  unambiguous 
translation  to  a  wide  variety  of  compiler- 
unique  target  environment  dialects.  For  this 
reason.  there  will  be  features  and  statement 
tyoes  Included  In  Workbench  COBOL  that  appear 
Identical  to  those  In  the  standard,  however. 

It  may  be  necessary  that  these  statements  be 
processed  by  the  Workbench  In  order  to 
produce  the  exact  form  required  for  a 
particular  target  dialect* 

3>  COBOL.woc  should  he  "rich*  enough  fer  easy 
use  by  programmers  In  the  development  of  com¬ 
plex  programs.  It  appears  that  there  Is  no 
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real  need  to  Include  *11  of  standard  COBOL  In 
C08QL*wbc.  What  Is  more  desirable  Is  to 
Insure  that  those  features  of  COBOL  that  are 
frequently  used  by  programmers  are  available 
In  Workbench  COBOL*  The  basis  for  the  design 
of  C080L.wbc  should  be  a  thorough  examination 
of  the  dialects  of  standard  COBOL  that  are 
encountered  on  the  target  environments  as 
well  as  a  study  of  the  types  of  statements 
that  are  actually  utlllied  by  C080L  program¬ 
mers.  (Initial  work  In  this  area  Is 
documented  In  Appendix  9* > 

The  solution  to  the  "t ransporta t Ion  problem"  seems  simple. 
If  programmers  arc  restricted  to  Implementing  their  programs 
using  only  the  features  and  format  of  "standard  COBOL." 
those  programs  should  compile  and  execute  on  jgy  machine. 
Unfortunately.  It  Is  not  that  easy.  Despite  the  existence 
of  two  COBOL  "Standards*  (68  and  7*>.  there  I*  no  real 
agreement  on  the  features  that  should  be  Included  In  the 
language.  Even  If  o  subset  of  language  features  could  be 
Identified  which  were  provided  by  all  COBOL  compilers, 
statement  syntax  varies  Between  compilers.  Even  In  those 
cases  where  the  syntax  used  to  express  a  particular  language 
element  by  two  different  compilers  Is  the  same,  the  language 
features  of  the  two  compilers  may  have  different 
Interpretations.  The  next  possible  solution  Is  to  select 
one  of  the  two  COBOL  Standards  as  the  "Standard  Standard" 
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and  to  develop  a  compiler  for  the  language  which  that  stan¬ 
dard  defines.  However*  compilers  are  developed  to  meet  the 
needs  of  a  particular  aacnlne  environment  and  Interpretation 
of  certain  features  is  ultimately  a  decision  of  the  compiler 
designer,  many  ooerations*  such  as  Input  and  output*  must 
depend  on  the  host  operating  system.  Since  different 
machine  environments  provide  many  different  features*  a 
standard  compiler  Is  not  sufficient  to  eliminate  the 
transportat  Ion  profile*;. 

Perhaps  a  solution  can  be  found  by  Investigating  the  method 
In  which  COBOL  programs  are  generally  transported  now.  The 
general  procedure  Is  to  locate  those  features  In  the  grammar 
of  the  source  compiler  which  are  not  the  samr  as  In  the 
grammar  of  the  target  compiler*  All  occurrences  of  these- 
statements  must  then  be  located  In  the  source  code  and 
translated  Into  the  corresponding  format  for  the  target 
system.  This  step  may  be  carried  out  with  the  aid  of  a  text 
editor.  The  next  step  Involves  locating  those  language 
features  which  are  provided  by  the  source  compiler*  but  are 
not  available  from  the  compiler  to  which  the  program  Is  to 
be  transported.  INote  that  the  reverse  step  Is  not  neces¬ 
sary*  hut  may  be  deslrec  due  to  the  possible  Increase  In 
program  efficiency.)  Those  sections  of  code  which  rely  on 
such  features  must  fie  Identified  and  recoded  uslno  only 
features  available  from  the  target  compiler.  If  the  source 
program  was  developed  for  a  compiler  which  accepts  a  very 
rich  dialect  of  COBOL  and  the  target  compiler  accepts  only  a 
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’slninun*  this  orocess  may  DC  very  long  and  difficult*  As 
this  cannot  be  automated*  th>*  possibility  of  introducing 
errors  to  the  translation  which  were  not  present  in  the 
original  is  very  high.  In  sooe  cases*  t  r  anspor  t  a  t  1  on  fray  be 
found  to  be  impossible. 

The  above  procedure  only  describes  the  transportation  of  o 
COBOL  projraa  from  one  particular  compiler  to  another 
particular  compiler*  The  entire  process  is  repeated  every 
tiae  the  source  program  is  to  be  moved  to  a  new  environment. 

Also*  since  no  compiler  is  accepted  as  the  "source"  cor* 
oiler*  oro'i'otj  s,iy  hove  to  be  transported  between  any  pair 
of  CO?!  01  compilers. 

In  an  easily  transported  COSOi.  program*  only  a  subset  of 
COBOL  is  used*  consisting  of  those  features  which  are 
available  in  some  for*  f roe  all  COBOL  compilers*  Where  this 
is  not  possible*  as  in  the  case  of  certain  machine  dependent 
features  such  as  occur  in  input  and  output  operations*  these 
co* o 1 l e r-un 1 aue  features  are  isolated  in  easily  identified 
sections  of  code  which  nay  be  changed  without  requiring  the 
recodlna  of  other  oortions  of  the.  program*  The  remaining 
differences*  due  to  differing  synta*  between  the  two  con- 
oilers*  nay  be  easily  eliminated  with  the  aid  of  a  te»t 
editor. 

The  process  described  above  permits  easier  transportation  of 
COBOL  programs  between  differing  machine  environments  but 
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st  111  require*  the  efforts  of  a  programmer  who  1*  cognisant 
with  both  the  source  anti  target  systems*  as  well  at  being 
fantlar  with  the  desired  behavior  of  the  program  to  be 
transported.  Since  programmers  are  an  expensive  resource* 
It  would  Co  oeslrable  to  automate  this  procedure. 

A  necessary  first  steo  In  attempting  this  automation  It  the 
reduction  of  the  number  of  pairs  of  dialects  between  which 
programs  are  tc  be  transported.  As  new  dialects  arc 
continuously  being  developed*  the  scope  of  application  of 
the  resultlnq  system  would  sc  unduly  l 1 *1 teo  were  the  choice 
of  target  l anyu^ges  to  be  restricted  In  any  manner.  Less 
difficulties  arise  In  Halting  the  number  of  possible  source 
dialects.  No  single  existing  dialect  contains  enough  of  the 
necessary  Information  to  peralt  easy  translation  Into  all 
possible  target  dialects.  As  a  result  It  Is  necessary  to 
develop  a  dialect  of  COBOL  particular  to  the  Uoribench 
system  (COBOL «»bcl.  COBOL. wbc  will  provide  the  user  with 
those  COBOL  features  that  can  be  supported  (~i  a  "portable" 
programming  environment.  Some  features  which  rely  on 
specific  hardware  or  operating  system  capabilities  cannot  be 
Implemented  on  all  target  machines  and  thus  wilt  not  be 
available  In  CLBOL.wbc*  COBOL.wbc  can  be  translated  Into 
any  of  a  number  of  target  dialects  (COBOL. k).  Much  of  the 
translation  process  will,  be  automated*  however*  because  of 
variations  In  computer  architectures  and  oraanl yat 1 ons*  some 
hueon  Intervention  will  still  be  required  to  translate  a 
program  from  workbench  COBOL  into  the  COBOL  dialect  that 
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will  execute  on  a  specific  mach1ne< 


2*2*5 


There  are  two  primary  products  Iron  the  Program  Processing 
Subsystem  of  the  workbench.  The  first  of  these  are 
■comp  1 l cr- Independent "  versions  of  the  program  or  module 
that  are  written  In  COBOL. wbc.  The  second  type  or  group  of 
products  are  the  “c o*p 1 l er-un 1 que“  versions  of  the  program 
written  In  a  specific  dialect  of  COBOL  f  COBOL  •'*  )  and  ready 
fo'  furthering  processing  ( t r an* l a t  1  on >  and  execution  by  a 
target  operating  environment.  The  first  class  of  products 
are  th»>  result  of  Csa&QiJ.2.Q  of  the  code  entered  by  the 
programme r  while  the  second  group  results  from  JLLtHliiiiStO 
of  COBOL. wbc  Into  a  target  COBOL  dialect. 


2.?. 5.1  Expansion 


The  purpose  of  orocras  expansion  Is  to  produce  compller- 
Inr.eoendent  program  modules  meetlno  the  standards  of 
COBOL. wbc  and  caoable  of  being  collected  together  with  other 
mo rules  to  oroduce  complete*  compiler-independent  programs. 


Input  to  t b *  program  expansion  process  consists  of  program¬ 
mer  specification  of  the  COeOL.wbc  text  for  the  module*  the 
name  of  the  module*  and  the  name  of  the  library  In  which  the 
module  Is  t r  be  found.  The  output  Is  a  program  module*  or 
complete  program*  meeting  the  standards  of  COBOL. wbc. 


Georgia  Institute  of  Technology 


C080L  Workbench 


•Tv 


Section  2 


CAPABILITIES 


Page  31 


Cspanslon  my  be  performed  relative  to  one  library  at  a 
time*  or  to  any  combination  of  libraries* 

2. 2* 5. 1.1  Lifiaoiiin  Uiliiiina  iH£  iinini  Ukixix 

The  General  Library  mill  be  available  to  programmers  on  all 
projects  and  In  all  application  areas  and  will  Include 
general-purpose  modules  which  are  frequently  used.  These 
modules  might  Include  the  following! 

-  data  Input  editing 

-  file  structure  definition 

-  report  generation 

Use  of  these  general  purpose  modules  will  eliminate  much 
repetitive  coding.  The  possibility  for  error  will  also  be 
reduced  greatly  through  two  causes.  mistakes  caused  oy 
clerical  error  will  be  less  ffeauent.  slncr  fewer  lines  of 
code  will  be  entered.  *^ore  significantly.  the  General 
Library  will  Include  only  modules  that  have  been  thoroughly 
tested,  reduclnc  the  posslbllty  of  Incorrect  code. 

2. 2. 5. i.2  Lijumlac  miLliloa  aj&x  i&fiLiiAJtian  Uaiaix 

The  Application  Library  contains  modules  developed  for  an 
applications  area  such  os  Inventory  or  payroll.  These 
modules  will  be  thorouahly  tested  before  addition  to  the  ap¬ 
plication  library.  The  application  libraries  might  Incluoe 
the  followlna! 


Georgia  Institute  of  Technology 


COBOL  workbench 


V  v 


SSS^saiaiS^s 


*9  *  -• 


See t Ion  2 


CAPABILITIES 


Pape  32 


-  a  collection  of  payroll  nodule* 

-  a  collection  of  nodules  developed  for  Inventory 
cont  rol 

Each  applications  area  wilt  possess  Its  own  library*  APPL 1  fi¬ 
nale  (c.g.  APPL 1  8-PAYROLL  or  APPL l B-INVCN) .  which  will 
contain  this  tyoe  of  nodule.  Projects  will  be  permitted  to 
sale  use  of  other  application  libraries  as  well  to  encourage 
standardization  and  to  decrease  maintenance  costs.  One 
esonole  of  this  potential  savings  Is  a  business  maintaining 
both  a  payroll  program  and  a  financial  report  generator.  If 
botn  of  the  programs  call  the  same  nodule  to  calculate  with¬ 
holding  t  a  « *  chances  In  the  t  a  *  laws  will  cause  less 
modification  to  the  currently  running  programs  than  If  each 
figures  the  t  a  *  separately.  Standardization  also  decreases 
the  errors  that  occur  when  different  heuristics  are  used  for 
the  sane  function  by  different  programmers. 

2. 2. s.  1.3  LtaiiQiittQ  uss  l&t  Etaitti  kifctinx 

The  Project  Library  contains  those  modules  currently  under 
develooaent  specifically  for  a  oartlcular  programming 
project.  Each  oroject  will  have  a  library*  PROJLIB-name* 
containing  these  modules.  This  library  differs  from  an  ap¬ 
plication  library  primarily  In  Including  modules  tailored  to 
a  sore  1  f  1  c  pro  J  ec  t . 

2.2.5. i. a  Liaiaiian  Ixaa  wl  Etnanii  UfciAix 

The  oroorammer  may  develop  a  personal  "shorthand"  notation 
to  ovoid  repetitive  programming  when  the  same  task  Is  to  be 
performed  a  number  of  times.  Personally  developed  modules 
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give  the  programmer  the  ability  to  enter  code  Into  the 
machine  In  a  convenient  form*  Call*  to  moautes  contained  In 
a  Personal  Library  must  be  expanded  Into  standard  COBOL.wbe 
at  toon  as  the  code  containing  those  non-standard  module 
calls  Is  made  available  to  other  members  of  the  programming 
project  (Included  In  the  Project  Library). 

2. 2. 5. i. 5  tifiiMiac  Ufia  iin  ini  kiiiar* 

The  Test  Library*  TCSTlIB*  *111  be  available  to  programmers 
on  all  projects  and  In  all  application  areas  to  assist  In 
module  and  program  testing  at  all  stages  of  project  develop¬ 
ment.  The  Test  Library  contains  modules  for  the  collection 
and  output  of  test  data*  dummy  moeules  to  be  used  In  testing 
calllnq  sequences*  ana  skeleton  programs  for  the  testing  of 
module  behavior  In  Isolation  and  as  a  rrsult  of  different 
catling  sequences. 

2. 2.5.2  Build  Programs 

in  order  to  build  a  program  or  system*  the  following  Input 
Is  needed: 

1>  A  collection  of  C0B0L*wbc  modules  selected  by 
the  orogrammer  In  order  to  produce  a  desired 
overall  functional  capability  In  the  output 
program. 

2*'  Special  Instructions  required  by  the  Program 
Preparation  Subsystem. 
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The  following  output  1*  generated: 

*  taailUifi*  but  QaO=£It&Uifikl£*  COBOL. wbc  program 
which  can  be  expanded  with  the  appropriate 
choice  of  target  machine  macro  library  Into 
an  executable  COBOL  program  In  a  form  which 
Is  acceptable  to  any  one  of  a  number  of  tar¬ 
get  COBOL  compilers. 

Specifically*  In  order  to  build  complete  COBOL. wbc  programs* 
the  Workbench  must  have  the  following  capabilities.  The 
Workbench  must  be  able  to 

1)  Collect  and  link  together  all  of  the  ap¬ 
propriate  Interface  components  of  the  Input 
COBOL. woe  modules  producing  an  output  program 
In  COBOL. wbc.  These  Interface  components 
Include  but  are  not  limited  to  data 
definitions  and  file  specifications. 

2)  Pcsolve  or  Identify  unresolvable  naming 
Inconsistencies. 

3)  Establish  consistency  In  data  and  file 
definitions  or  Identify  possible  problems 
that  might  result  from  Inconsistencies. 
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2. 2. 5. 3  Transportion 

One  of  the  most  Important  capabilities  of  the  Workbench  Is 
the  dovolopasnt  and  transportation  of  portable  COBOL 
programs.  This  goal  Is  achieved  by  the  development  of 
baseline  COBOL  programs  In  a  compiler-independent  form  <1n 
COBOL. wbci  and  the  autoaat  1 9  translation  of  thesr- 
proarnms  Into  the  COBOL  dialect  of  a  particular  target  com¬ 
piler  system. 

This  translation  could  hove  been  accomplished  by  the 
development  of  a  new  COBOL  dialect  and  of  a  new  compiler  to 
accept  this  language.  This  was  not  the  chosen  solution.  A 
new  COBOL  compiler  and  a  new  dialect  would  only  add  to  the 
problem,  while  It  sould  be  possible*  assuming  programmer 
and  Industry  acceptance  of  the  new  dialect*  to  develop  new 
proqrams  which  could  run  on  any  target  machine*  the  addition 
of  new  environments  to  the  original  set  of  target  machines 
would  be  an  extremely  difficult  proceeding  and  would 
probably  result  In  the  same  chaotic  situation  presently 
existing  with  the  "standard  COBOLs."  Worse*  only  new 
systems  would  be  portable.  Systems  would  be  able  to  Include 
previously  written  software  only  after  extensive  rewriting 
to  translate  the  old  proqram  Into  the  new  lanouage.  Final¬ 
ly*  development  of  yet  another  COBOL  compiler  does  nothing 
to  address  the  problem  of  developing  rfluftip It  codft. 
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The  chosen  solution  1*  to  express  those  functions  and 
statements  for  which  a  como  1 l  er-dependent  Imptementat  Ion  Is 
necessary  as  special  statements  In  a  compiler-independent 
rooresentaf  Ion  of  the  program*  and  then  to  "expand"  these 
statements  separately*  relative  to  each  target  compiler. 


2*2*6  Sciidkairfi  Ectaim 


A  major  expense  In  the  development  of  automated  Information 
systems  has  been  the  high  cost  for  the  redesign  of  the 
system  after  the  Initial  prototype  has  been  Implemented. 
This  Is  especially  true  when  a  separate  oraanlzatlon  Is 
preparing  the  program  for  another  organization  which  Is  the 
proponent  or  motivator  for  the  system  to  be  designed.  One 
aeproaen  that  has  been  proposed  to  lower  this  Initial  design 
cost  Is  the  utilization  of  a  breadboard  program*  or  system* 
tnat  provides  the  basic  functionality  of  the  desired  system 
without  the  hlqh  expenses  associated  with  detailed  and  com¬ 
plete  development.  This  breadboard  program  or  prototype 
could  then  be  demonstrated  to  the  proponent  organization  and 
feedback  on  the  design  would  be  obtained  at  a  much  earlier 
stage  and  at  a  much  lower  cost  without  complete  development 
being  required. 


The  character  1st les  of  a  breadboard  program/prototype  system 
woutd  be  that  Jlfiil  of  the  desired  functionality  would  be 
present  In  the  system?  however*  the  performance  of  the 
system  would  certainly  not  be  ootlmlzed  or  even  "welt 
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engineered."  To  the  *9x1 mum  extent  possible*  the  breadboard 


system  would  be 


nbled  out  of  reusable  modules  of  code 


which  provide  the  functionality  desired*  or  close  ap- 
proxleatlons  thereto.  The  overall  objectives  of  breadboard- 
Ing  are  to  provide  q^1  <; k  and  Igw-cost  prototypes  of  systems 
under  design  so  that  meaningful  feedback  may  be  obtained  at 
the  earliest  date  possible. 
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The  nodular  approach  to  the  preparation  of  complex  systems 
significantly  aids  In  the  development  of  Quality  programs* 
yhlle  It  Is  true  that  In  most  large  systems  absolute  program 
accuracy  can  only  be  approximated*  the  separate  testing  and 
verification  of  the  "correctness"  of  Individual  modules* 
before  the  oocules  are  combined  Into  a  single  program  unit* 
will  lead  to  the  development  of  quality  programs  In  an 
economic  fashion. 


Program  testing  Is  aided  by  a  collection  of  utility  func¬ 
tions  and  modules  which  are  used  by  the  programmer  to  test 
both  nodules  and  programs.  Besides  providing  the  op¬ 
portunity  for  functional  testing*  utilities  will  be  provided 
to  aid  In  the  measurement  of  performance.  Specific 
utilities  which  might  be  Included  for  this  purpose  Include! 

1)  sain  orograas  to  Invoke  the  module  In  Ques¬ 
tion  and  print  Input  and  output  ("test  har¬ 
nesses") 

2)  routines  to  generate  random  Input  data  meet¬ 
ing  a  specified  COBOL  format 


3>  routines  to  generate  random  Input  files  meet¬ 
ing  the  conventions  of  a  particular  compiler 


and  machine 

a)  routines  to  collect  performance  data*  Includ¬ 


ing  time  and  space  usage 

These  utilities  are  placed  In  a  special  test  library  wh'ch 


iL  *:  *%. 
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contain*  tool*  used  for  testing  module*  and  program?*  Some 
of  the  essential  tool*  are: 

1)  Te*t  Control  System 

2>  Te*t  Harness 

3)  Automatic  Test  Data  Generators 

A)  Automatic  Verification  System 

5)  Object-Time  Monitors 

2*3*i  fiaiii  lai  itiUoa  Samel 

Progrom  testing  capabilities  are  Included  In  the  Workbench 
to  provide  for  the  testing  of  COBOL.wbc  nodules  produced  us¬ 
ing  the  Workbench  Module  Preparation  Subsystem  prior  to  the 
Inclusion  of  these  modules  In  COBOL.wbc  programs.  The  fol¬ 
lowing  goals  must  be  met: 

1)  Drov1de  a  test  environment  covering  both 
language  tests  as  well  as  I/O  and  data  tests 
to  easily  check-out  the  modules  as  they  are 
produced  by  the  above  process. 

2)  Permit  the  collection  of  data  about  module 
performance  before  the  Inclusion  of  the 
module  In  a  finished  program. 

3>  Test  module  behavior  as  It  will  perform  on 
each  target  machine.  This  will  Involve  con¬ 
verting  the  orlcitnat  COBOL.wbc  module  Into 
each  member  of  the  related  family  of  C080L.1 
modules*  providing  C0B0L.1  drivers*  and 
executing  each  of  the  resultant  proqrams  on 
the  appropriate  machine. 


Georgia  Institute  of  Technology 


COBOL  workbench 


Section  ? 


C  APAB 1 L  J T ICS 


Page  *0 


°rov1de  utility  routine*  to  aid  the  program¬ 


mer  In  the  generation  of  test  data  meeting 
particular  program  reoulrements  as  specified 
oy  the  appropriate  data  declaration  division. 


(Optional)  Provide  utility  routines  to  enable 
the  programmer  to  nctcrslne  It  the  set  of 


test  cases  is  adeauate  to  properly  test  the 
modu tar  logic. 


2*3.2  I  Hi  iUCOiii 


One  of  the  major  tools  to  be  used  In  program  (or  module) 
testlno  Is  the  tpftt  harness «  This  main  or  driver  program 
serves  as  a  framework  which  supplies  appropriate  Inputs  to  n 
module.  It  also  records  the  outputs  produced  by  the  module 
(alonq  with  the  associated  Inputs)  In  such  a  manner  that  the 
programmer  can  determine  whether  the  output  produced  Is  In 
accordance  with  the  specifications  established  by  the  system 
des 1 gner • 


2.s.3  lui  isntcai  ixalu 


The  Test  Control  System  causes  the  tests  to  be  executed. 
Throuoh  the  Test  Control  System,  the  appropriate  test  data 


is  rctrlr  ed»  the  driver  or  test  harness  1$  executed  using 
the  prescribed  test  data,  and  any  postprocessing  of  the  out¬ 
put  from  the  test  harness  Is  performed.  The  Test  Control 
System  automatically  modifies  the  source  code  as  necessary 
when  performance  evaluations  are  conducted.  In  the  case  of 
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the  testing  of  nodules  which  perform  certain  file  processlr.q 
activities  Internally*  the  Test  Control  System  will 
automatically  compensate  for  differences  between  the  way  In 
which  files  are  stored  and  accessed  during  the  test  and  the 
way  In  which  files  are  to  be  managed  under  the  eventual 
production  system* 

It  it,  through  the  Test  Control  System  that  most  of  the  tools 
used  In  the  program  testing  phase  are  sequenced*  monitored* 
and  controlled*  The  Test  Control  System  con  also  gather* 
record*  and  report  In  an  appropriate  form  Information  to  be 
used  In  the  management  of  program  testing.  Pertinent  In¬ 
formation  regarding  each  test  (who  tested  what  module*  whot 
data  was  used  In  the  test*  when  was  the  module  last  tested* 
etc.)  are  logged  by  the  Test  Control  System, 

2*3.4  i til  bau  fitnicillaa 

While  the  testlnq  of  Individual  modules  or  components  of  a 
large  system  may  significantly  aid  In  error  prevention*  each 
Individual  module  must  be  exercised  for  the  purpose  of  error 
defection*  The  primary  goal  of  the  testlno  process  is  to 
make  mistakes  happen  (If  errors  do  In  fact  exist)  with 
results  that  can  be  easily  recognized  as  Incorrect  and  which 
provide  enouqh  Information  about  program  behavior  that  the 
errors  can  be  found  gulckly  and  corrected.  In  order  to  ac¬ 
complish  this  task*  enough  Inputs  must  be  tested  to  exercise 
the  program  or  module  under  consideration  completely. 
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The  develooaent  of  sufficient  test  data  Is  an  exacting  task* 
It  Is  not  enough  that  a  large  nuaber  of  Inputs  are  tested! 
the  variety  of  Inputs  tested  Is  also  Important  since  each 
control  path  In  the  code  wust  be  examined.  If  the  test  data 
Is  prepared  wanually*  control  paths  may  be  *1ssed»  causing 
errors  to  pass  undetected  until  the  systea  Is  In  production* 
and  any  errors  found  will  require  expensive  correction*  The 
preparation  of  "good"  test  data  by  aanual  weans  Is  ar.  ex- 
tre.nely  difficult  task  which  requires  extensive  analysis  of 
branching  and  control  flow*  The  Workbench  must  therefore 
provide  a  sechjnlsx  to  facilitate  the  generation  of  a  suf¬ 
ficient  nu*oer  ana  variety  of  test  cases  tor  each  nodule  to 
be  tested.  This  facility  *ust  i>rov<de  for  the  automatic 
generation  of  test  data  using  (at  a  »1n1i*u*>  as  Input  the 
OATA  DIVISION  Of  tnc  test  f arnesi  and  the  test  definitions 
given  by  the  nrograxurr  In  scae  procedural  notation.  It 
will  also  Demit  the  generation  of  test  data  by  combining 
records  fro*  existing  files  of  test  waterlal  and  Integrating 
these  records  Into  a  c o*p r chens 1 ve  set  of  test  data*  This 
latter  capability  *oy  be  used  to  Insure  that  all  wodules  In 
a  particular  proqran  receive  final  testing  over  an  Identical 
data  set  oroduced  as  the  union  of  test  Input  generated  for 
the  Individual  modules. 
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2*3.5  Mrnik  XttlllMllaa  ixilu 

A  number  of  tools  will  be  available  for  the  analysis  of  out¬ 
put  resulting  fro*  execution  of  the  test  harness.  An  output 
analyser  would  permit  comparlston  of  outputs  with  correspon¬ 
ding  Inputs*  with  previously  generated  outputs*  or  with 
predetermined  results  presented  to  the  analyser  In  some 
fore*  and  would  report  the  discrepancies  on  an  exception 
basis*  Standard  statistical  library  routines  would  be  used 
to  Interpret  the  output  fro*  the  object-time  monitoring 
facility. 

2.3.4  aklt&lsIUt  flflflllan 

Options  provided  within  the  Test  Control  System  will  permit 
the  "Instrument  at  Ion*  of  the  module  being  tested  In  such  a 
way  that  program  execution  efficiency  can  be  evaluated.  The 
areas  within  a  given  module  which  will  receive  closest 
monitoring  will  be  determined  by  usage  statistics  provided 
at  the  source  program  paragraph  level. 
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2.4  tmm  uim&ML 


The  maintenance  of  oroqrans  that  have  already  been  developed 
and  olaced  Into  operation  Is  widely  acknowledged  as  the  most 
eapcnslve  port  ot  the  life-cycle  cost  of  such  programs.  The 
COBOL  p rod r amme r * s  Workbench  fully  acknowledges  this  fact 
and  provides  complete  support  for  maintenance. 

2*4.i  mutt  al  fliAniiiiM&t  Lkiltiilti 

Referring  to  Eiqure  1.3-1*  it  con  be  seen  that  there  are  two 
dimensions  to  the  maintenance  activities  supported  by  the 
Workbench.  The  first  of  these  Is  the  maintenance  that  must 
be  performed  on  compiler-unique  VERSIONS  of  the  program  in  a 
■qu 1 c k-f 1 *"  Banner  to  correct  logical  errors  in  the  develop¬ 
ment  o<  the  baseline  program  or  Workbench  errors  in  the 
translation  of  that  oroqra*  to  the  compiler-unique  en¬ 
virons  ents.  Each  VERSION  of  the  program  presents  a  separate 
maintenance  problem  and  MODIFICATIONS  of  VERSIONS  are 
generated  individually  as  required. 

The  other  dimension  of  maintenance  Is  the  preDarat;on  of  a 
new  release  of  the  baseline  program.  In  this  Instance* 
there  is  only  one  program  being  maintained. 
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2.4.2  niipitaaoii  Sums  cl 

The  support  for  program  maintenance  provideo  by  the  COBOL 

Programmer**  Workbench  con*1*t*  of  several  capabilities. 

1)  The  concept  of  a  single,  controlled  baseline 
program  reduces  the  amount  of  maintenance 
programming  reoulred  In  a  mul 1 1  pi e - 1 a rge t 
operating  environment. 

2)  The  programmer**  environment  provided  by  the 
Workbench  for  the  preparation  of  programs 
also  greatly  facilitate*  the  preparation  of 
modifications  to  previously  developed 
nroqram*. 

The  on-line  documentation  system  and  the 
capabilities  It  provide*  for  linking  comments 
to  specific  portions  of  the  documentation 
test  greatly  facilitate  what  Is  perhaps  the 
most  time  consuming  activity  In  maintenance 
operations  -  the  correlation  of  all  of  the 
Information  applicable  to  the  original 
program  and  the  changes  to  be  made. 

a  )  The  (Document  at  Ion  Control  System  also 
provides  for  the  control  of  multiple  versions  1 
of  both  code  and  test  so  that  the  maintenance 
orogrammer  can  easily  check  out  a  new  v.-rslon 
of  a  program  without  disturbing  the  otd  one. 
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One  of  the  major  tasks  faced  by  the  designers  of  software 
systems  Is  the  production  and  maintenance  of  complete 
documentation  Including  specifications*  deslons*  user  and 
reference  manuals*  and  reports  as  well  as  the  program  code. 
To  encourage  the  production  and  maintenance  of  current  and 
complete  documentation,  the  Workbench  will  be  equipped  with 
a  nroad  range  of  tools  which  are  designed  to  assist  In  the 
preoara t Ion  of  all  of  the  system  documentation  reoulreo  for 
the  suoport  of  prototype  systems*  the  base-line  system*  and 
those  versions  of  the  system  produced  to  run  on  specific 
target  machines.  The  documentation  toots  provided  by  the 
workbench  will  be  simple  to  use*  will  Interface  with  each 
other*  and  will  provide  additional  capabilities  which  make 
the  documentation  task  less  burdensome  to  the  documentor  and 
Increase  his  productivity. 


2.5.1  SlUxlgl  Si  i Jti 


c1oure  2. 5.1-1  depicts  the  flow  of  text  and  commands  that 
will  occur  durlnq  the  preparation  of  system  documentation. 
The  documentor  will  be  able  to  both  enter  an  orlolnal 
document  as  well  as  modify  existing  documents.  The 
documents  will  be  stored  In  a  series  of  libraries.  In  ad¬ 
dition*  It  will  not  be  necessary  for  a  document  to  be 
entered  In  a  final  finished  format*  Instead*  a  separate 
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FIGURE  2. 5.1-1 

PREPARATION  ANO  MODIFICATION  OF  SUFF0RTIN6  DOCUMENTATION 
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process*  the  Formatting  Process*  will  be  available  to  per¬ 
form  these  formatting  duties  (see  section  2.7.2).  By  making 
formatting  a  separate  procedure*  one  mill  only  have  to  save 
and  revise  the  unformatted  test  of  documents.  This  will 
make  the  task  of  modifying  documents  easier  since  It  will  be 
possible  to  make  changes  without  worrying  about  the  effect 
of  those  changes  on  the  format  of  the  final  output. 

2.5.2  flnsllftt  CfllMlIQt  HiOdllQfl 

One  of  the  essential  reoulrements  for  the  Documentation  Sub¬ 
system  Is  that  It  be  available  for  on-line  use.  This  wilt 
enabse  the  documentor  to  compose  and  enter  documentation 
Into  the  system  In  a  single  step.  In  addition*  he  will  be 
able  to  CKtract  test  from  other  documents  for  use  In  another 
document  that  Is  being  orepared  or  modified. 

2.5. 2.1  Preparing  Documents 

The  documentor  will  be  able  to  enter  documents  In  an  on-line 
fashion.  Intermingled  with  the  normal  test  of  these 
documents  will  oe  formatting  commands  which  will  be 
Interpreted  at  a  later  stage  by  a  Formatting  Process.  These 
commands  will  allow  the  documentor  to  control  the  format  of 
the  flnat  document  (see  section  2.7.2).  For  example*  one 
will  be  able  to  underline  and  bold-face  desired  words  In  the 
text  by  simply  Inserting  the  appropriate  commands  In  the 
proper  position  gf  the  unformatted  text. 
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The  documentor  wilt  he  able  to  easily  edit  the  Input  text 
during  the  document  preparation  phase*  He  will  have  the 
capability  to  Insert*  delete*  or  modify  as  well  as  to  reor¬ 
der  parts  of  the  text.  The  documentation  process  often  In¬ 
volves  copying  text  from  other  sources*  for  example*  other 
documentat 1  on  or  actual  proqram  text.  The  latter  situation 
often  arises  when  one  wants  to  present  an  example  within  the 
documentation  or  when  one  wants  to  discuss  the  text  of  the 
program.  Thus*  an  Important  editing  feature  of  the 
Ooc umentat 1  on  System  will  allow  test  from  any  source  to  oe 
Inserted  Into  any  document  while  It  Is  being  prepared  or 
modified.  Since  the  copy  capability  Is  Included  as  part  of 
the  editing  capabilities*  one  will  be  able  to  obtain  text 
fro*  other  sources  and  then  trim  and  modify  the  text  to  suit 
his  needs. 

2. 5.2.2  Updating  Oocumenta 

The  caoabltltles  orovlded  by  the  Workbench  for  originally 
preparing  documents  will  also  be  available  for  updating 
documents.  The  documentor  will  be  qlven  editing 

|  capabilities  which  enable  him  to  Insert*  delete*  reorder* 

I 

i 

t 

?  and  modify  text.  As  mentioned  above*  he  will  alto  be  able 

I 

'i  to  copy  text  from  a  variety  of  sources*  Includlnq  proqram 

] 

text*  and  will  be  able  to  perform  this  while  entering  or 
modifying  the  original  document. 


Georgia  Institute  of  Technology 


COBOL  Workbench 


j 


Section  2 

i 

t 


CAPABILITIES 


Page  50 


a 

I 

1 


2.6  aflsmmi  mm 


Programs  and  supporting  documentation  often  exist  simul¬ 
taneously  In  several  different  forms.  For  example*  a 
program  may  be  In  production  use  while  at  the  same  time  Im¬ 
provements  are  eelnq  developed  for  It.  A  form  of  document 
control  that  can  selectively  retrieve  any  specified  version 
of  a  document  (s  required.  The  facility  provldlnq  document 
control  must  provide  the  user  accest  to  any  revision*  allow 
the  user  to  create  new  revisions*  and  Insure  that  no  change 
mace  to  a  document  Is  lost.  The  last  capability  will  help 
to  Insure  against  an  accidental  loss  of  Information. 

2.6.1  amxltJt  a!  Oataitni  Capital 

The  Document  Control  System  will  handle  all  programs  and 
supporting  documentation.  Any  user  or  process  needing  a 
specific  revision  of  any  document  (the  term  document  refers 
to  both  programs  and  documentation)  will  request  that 
revision  from  the  Document  Control  Process.  Thus*  both  the 
Documentation  Preparation  System  and  the  Program  Preparation 
System  will  have  to  Interact  with  the  Document  Control 
System  In  order  to  obtain  documents.  The  Document  Control 
System  will  store  All  revisions  of  all  documents  In  various 
l  Ibrar les. 


Sri 

1 
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2*6*2  Audit  if. i, n  sti  fifamflii 

The  Document  Control  System  will  automatically  maintain  an 
audit  trail  of  all  changes  made  to  a  document  (see  Appendix 
3).  This  will  allow  the  programmer  or  systems  analyst  to 
Identify  changes  made  to  a  document  In  a  chronological  man¬ 
ner.  Thus*  corrections  need  not  be  considered  permanent 
because  they  can  always  be  recovered.  It  should  be  noted* 
though*  that  the  Document  Control  System  will  never  discard 
any  change?  rather*  If  the  change  Is  not  desired*  It  simply 
will  not  »e  applied  during  the  construction  of  a  particular 
revision. 

2.6.3  AdlLllx  J U  oiinliin  QlfUrtol  ailuiu^Mm 

The  Document  Control  System  will  provide  the  capability  to 
maintain  separate  RELEASES  of  all  documents.  The  need  for 
separate  RELEASES  occurs  when*  for  example*  one  RELEASE  of  a 
oroaro*  1$  In  oroauctlon  while  a  newer  RELEASE  Is  In 
development.  In  addition  to  maintaining  separate  RELEASES* 
one  eust  be  able  to  maintain  the  different  VERSIONS  of  all 
RELEASES.  Thus*  the  Document  Control  System  will  allow  one 
to  obtain  or  create  any  VERSION  of  any  RELEASE  of  a 
document . 
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2.4.4  UnUfli  ftl  Cautoli  an  ttfltyitoU 


To  encourage  as  much  feedback  as  possible  on  programs  and 
supporting  documentation*  the  Document  Control  System 
provides  the  ability  for  user  comaents  about  documents  to  be 
dated  and  linked  to  the  document  to  which  they  refer.  Thus* 
users  can  comment  on  any  errors  which  they  believe  they  have 
discovered  or  aake  suggestions  for  changes  to  the  documents. 
The  systems  analyst  responsible  for  a  document  will  be  able 
to  examine  all  comments  pertaining  to  the  document.  He  car. 
then  act  upon  them  and  report  back  to  the  orlolnator  of  the 
comment  as  to  the  status  of  the  document  or  the  point  raised 
by  the  user. 
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2.7  Miyam  ElMlimM 


^•t.i  gtaacn  ecfiflatliAQ 


The  workbench  has  the  capability  to  produce  record  or 


documentation  copies  of  the  various  VERSION'S  of  the  source 
code*  however.  It  cannot  produce  the  object  code  version  of 


the  proora*.  That  has  to  be  produced  In  the  target-compiler 
env 1 ronren  t . 


2.7.2 


Th<>  workbench  will  be  able  to  process  the  documents  as  they 
are  stored  In  the  various  libraries  and  produce  printed 
reports  which  are  formatted  according  to  appropriate  stan¬ 
dards.  The  workbench  will  provide  a  Formatting  Program 
which  will  accept  commands  Imbedded  In  the  text  of  the 
documents.  These  commands  will  Inform  the  rori»atter  as  to 
how  the  text  should  be  prlntedl  for  example,  what  words 
should  be  underlined  or  bold-faced.  what  text  should  be 
centered,  how  many  tines  should  be  skipped  between  sections 
of  the  text.  etc.  In  addition,  the  Workbench  will  provide 
the  means  for  defining  documentation  standards  and  aiding 
documentors  In  following  these  standards. 


Georgia  Institute  of  Technology 


COBOL  Workbench 


r&Jrfi 


Section  2  C AP4B  III T  IES 

FIGURE  2, 7.2-1 
PRODUCTION  OF  DOCUMENTATION 


Page  55 


I  I 

|  Documentor  | 

I. _ I 

t 


_ f _ 

I  l# 

|  Formatting  | 

I  Proce**  j< 

i _ i 

I 

I 

I 

I 

I 

i 

I 

I  I 

|  Formatted  | 

|  Document*  j 

I _ I 


I  I 

>j  Librarian  | 

I _ ! 


1 


>1 

I 

-I 

I 


Libraries 


I 

I 

I 

\ 


Text 

FIom 


> 


< — — ----- 


•  Command 

•  Flow 

f 


<•••••••»• 


Georgia  Institute  cf  Technology 


COBOL  Workbench 


Section  2 


CAPABll  I  TKS 


Page  56 


2. 7.2. 1  Formatting 

The  Workbench  will  contain  a  formatting  Process  which  will 
orlnt  doc u»en t a 1 1  on  accordlna  to  the  users  specification  or 
a  standard  set  of  specifications  stored  In  the  General 
Llorary.  The  user  will  taped  commands  In  the  documentation 
test  stored  In  libraries  which  tell  the  formatting  Process 
what  for*  of  cutout  Is  desired.  There  will  be  default  set¬ 
tings  for  oaro-cters  not  specified  by  the  user.  Thus.  the 
Formatter  will  produce  a  formatted  document  according  to  the 
commands  specific  o'  w  1 1  n  in  the  t  e  *  t  utilizing  default  set- 
tin's  for  these  options  not  specified  by  thr  user. 

2. 7.2.2  Documentation  Format  Standard* 

The  workbench  will  also  provide  the  capability  to  define 
documental  Ion  standards  and  aid  documentors  In  following 
these  standards.  Standards  may  vary  from  project  to  project 
or  from  one  type  of  document  to  another  within  a  single 
or  d  <  cc  t «  The  Workbench  will  provide  a  uniform  technique  to 
locate  definitions  of  the  various  standards  and  the  means  to 
automatically  produce  documentation  meeting  those  standards. 
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SECTION  3 

FUNCTIONAL  COMPONENTS  OF  THE  COSOL  PROGRAMMER'S  WORKBENCH 


3.1  mmu  ftf.  Mammai  amamuus  m  mmuim 

The  ujff  see*  the  workbench  At  a  collection  of  capabilities 
and  function*  that  provide  hi*  with  support  In  accompl 1  thing 
nit  programming  and  documentation  tasks.  Functionally, 
these  capabilities  can  be  divided  Into  several  motor  sub¬ 
system  or  components  as  shown  In  Figure  3.1*1.  Since  the 
•ajor  activity  of  the  workbench  1»  the  preparation  ano 
processing  of  docu»rnts.  whether  they  are  program  modules  or 
supporting  documentation,  the  subsystem  providing  control  of 
those  documents  It  certainly  a  central  component  of  the 
Workbench.  The  Document  Control  Subsystem  at  shown  In 
c1oure  3.1-1  sight  be  compared  to  the  file  system  of  a 
reqular  computer!  however,  as  pointed  out  In  Section  2  of 
this  report,  the  workbench  envlslont  the  *a1ntenance  of  mul¬ 
tiple  versions  of  the  same  document,  and  the  support 
provided  by  the  Document  Control  Subsystem  Is  much  *ore  ex¬ 
tensive  than  that  orovtoed  by  normal  file  systems. 
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FIGURE  3.1-1 

MAJOR  FUNCTIONAL  COMPONENTS  OF  THE  COBOL  WORKBENCH 
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3.2  eBQfi&AflBiM  BitamiLfl 


3«2.i  gtaam  grtamilaa 

3.2. 1.1  Workbench  COBOL  -  COBOL. wbc 

Workbench  COBOL  (COBOL.wbc)  Is  the  portable  version  of 
COBOL.  It  nai  been  designed  to  provide  the  user  with  as 
many  of  the  capabilities  of  fult  COBOL  as  may  be  supported 
In  o  "portable"  programming  environment.  COBOL. wbc  was 
developed  fror  standard  COBOL  with  the  explicit  goal  of 
producing  a  COBOL  dialect  which  would  peratt  a  COBOL  program 
developed  on  one  machine  to  be  executed  on  another  without 
tedious  and  er ror-produc log  hand-modification.  However. 
COBOL. wbc  ii  oal  lilt  liAiiHl  taaiao  of  COBOL  ap¬ 

plicable  to  all  of  the  target  computers  selected?  Instead. 
1t..s  on » 1st  s  of  the  to*«on  subset  of  COBOL  applicable  to  all 
of  the  selected  target  computers  (COBOL. ccs>  plus  those 
those  features  heavily  used  by  COBOL  proaraasers  even  If 
these  features  are  net  directly  oortable.  The  translation 
of  this  latter  group  of  features  Into  co*r1  er-unlque  code 
Is  a  function  of  the  Program  Processor. 
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COr,Ot  «  n*ao  Is  this  project**  first  appro*  1*. it  lor*  to 
CO^OL.whc.  COBOL. wbc  consists  of  those  elements  of  COBOL 
which  are  common  to  all  COBOL  compilers  plus  a  number  of 
other  ceoaollltles  which  cannot  De  directly  Implemented  In 
the  same  format  by  all  compilers.  The  nature  and  type  of 
these  capabilities  which  oust  be  provided  In  order  to  permit 
the  develoonent  of  useful  COBOL  programs  Is  not  yet  known. 
A  number  of  COBOL  capabilities  (such  as  data  declaration) 
are  assumed  to  be  necessary!  these  capabilities  will  be 
Included  In  COBOL. deso.  Other  capabilities  will  be  added  to 
dOBOL.de-.o  as  their  usefulness-  Is  demonstrated.  The 
eventual  product  of  tnls  process  will  be  COBOL. wbc. 

For  (he  ourposes  of  this  report,  only  a  casual  distinction 
Is  made  between  COBOL. wbc  ana  COBOL. demo.  COBOL. wbc  Is  used 
whenever  cither  COBOL.dcmo  or  COBOL.wbc  might  be  meant. 
(cor  e* a nolo.  at  different  stages  In  the  Workbench’s 
%)c  vc  l  ooaen  t  > .  COBOL. demo  Is  used  only  In  reference  to 
developmental  activities  which  will  be  over  when  the  Work¬ 
bench  systen  Is  complete. 

3.?.  l.J  COBOL  Screen  Editor 

I"  addition  to  the  standard  features  available  In  a  com¬ 
prehensive  screen  editor  ( 1 1 ne-a t 1 1  me  deletions.  ad¬ 
ditions.  search,  scan  and  substitution,  and  full  screen 
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display  of  adjacent  te*t>»  the  screen  editor  utilized  In  the 
programmer**  environment  would  alto  contain  features  that 
are  specifically  tailored  to  the  preparation  of  COBOL 
programs.  These  features  would  be  capabilities  such  as 
automatic  formatting*  automatic  searching  for  sections  of 
the  program  by  name*  etc. 

3.2.1. a  Standards  Enforcer 

The  aost  laportant  standards  enforcer  Is  obviously  the  one 
for  COBOL. wbc.  This  would  function  In  a  wanner  very  similar 
to  presently  eilstlng  standards  enforcers.  It  would  operate 
as  a  preprocessor  on  the  source  code  ensuring  that  prooraes 
contained  only  stateeents  taken  fro*  COBOL. woe  or  properly 
formatted  references  to  reusable  aodules. 

If  It  Is  desired  that  the  Workbench  support  COBOL  program- 
alnq  In  a  specific  dialect  tCOBOL.kl*  then  a  different  stan¬ 
dards  enforcer  would  have  to  be  provided  for  that  dialect  of 
COBOL. 


3*2*2  Etaagii  Emiitlna 


\ 


3.2. 2. 1  Library  Support 

A  nu*ber  o  *  support  libraries  oust  be  wade  available  to  the 
orogra*  designer.  The  Workbench  provides  the  capability  for 
each  Installation  to  develoo  and  maintain  a  useful  and 
meaningful  collection  of  macro  and  module  libraries  taltored 


Georgia  Institute  of  Technology 


COBOL  Workbench 


- - 

•» 

nn^iMj-vir.iriWri  m  am  rH—**-  t 


^fc t  1 on  3 


FUNCTIONAL  components 


Page  62 


to  the  needs  of  the  Individual  Installation.  These 
libraries  are  described  In  detail  In  Section  3*5.1. 


A  COBOL  •  ubc  program  containing  references  to  reusable 
modules  say  be  esoanded  Into  an  eoulvalent  COBOL. wbe  program 
relative  to  any  one  or  more  of  the  module  libraries.  For 
e* oriole*  the  reusable  module  references  used  by  an  In¬ 
dividual  programmer  as  abbreviations  may  be  removed  while 
leavlnq  module  calls  iron  the  Project*  Application*  and 
General  Libraries.  Translation  of  a  C080L.wbc  program  Into 
the  equivalent  COBOL  program  for  a  particular  tarqet  machine 
( COBOL • k  >  shoulo  occur  only  after  all  reusable  module 
references  have  been  enpanded. 


The  macro  processor  uses  a  search  rule  to  locate  the  macro 
cefinltlon  corresponding  to  a  specific  module  call  In  much 
the  sasc  way  that  a  loader  searches  for  load  modules.  Un¬ 
less  otherwise  specified  the  search  rule  used  1st 

1)  prrsonal  Library 

2)  Project  Library 

3)  Test  Library  (utilised  only  when  specifically 
r  eoue s  t  ed  > 

*>  Application  Library 

5)  General  Library 

6)  fo*p1 ler-Unlouf  "jero  Library  (utilized  only 
when  transporting  a  COBOL. wbc  program  to  a 
spec  1 f 1 c  compl  1 cr ) 

In  this  way*  Improvements  to  modules  already  Included  In 
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standard  libraries  nay  be  tested  without  recopying  the  stan¬ 
dard  library  or  aodifying  program  to  use  new  naaes  for 
nodules. 

3 .3.2.2  Program  Processor 

Using  the  tools  described  in  the  previous  sections*  the 
pro grander  develops  a  COBOL. wbc  proqran.  Before  this 
progra*  can  be  executed  on  sone  target  machine*  processing 
will  be  necessary  to  convert  the  COBOL.wbc  code  into 
coapi l er-ac cep t ab le  code. 

The  nature  and  extent  of  processing  needed  depenj*  on  the 
nature  of  the  task.  The  Workbench  is  a  flexible  tool* 
suitable  for  use  in  a  number  of  ways*  ranging  from  the  most 
single  to  the  <*ost  complex  appt icat ions.  In  its  simplest 
aode*  the  workbench  serves  as  a  text  editor  and  librarian. 
In  its  *ost  conplex  node*  the  Workbench  provides  the 
proqr»**f r  with  all  of  the  tools  necessary  to  produce  COBOL 
code  which  is  noth  portable  and  reusable. 

Basically*  the  proqri«  Processor  In  the  Workbench  can  be 
used  to  expand  calls  to  reusable  nodules  Into  in-line  code 
and  to  translate  program  written  in  COBOL.wbc  into  programs 
which  will  execute  correctly  on  a  particular 
co«piler/«tich1ne-environarnt. 
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SUBSYSTEM 


A*  contrasted  to  the  various  steps  Involved  In  programming* 


the  three  aspects  of  documentation  ---  preparation*  control* 


and  production  ---  do  have  rather  clear  divisions  and  can  be 


discussed  separately* 
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s.4  QflcuB&mmtt  nuMiim 

To  encourage  the  production  of  complete  and  up-to-date 
documentation*  the  Workbench  provide*  an  environment  well 
suited  to  the  documentor.  This  environment  Include*  tools* 
libraries*  8nd  a  set  of  documentation  format  standards.  A 
major  portion  of  thl*  environment  1*  provided  by  the  Text 
Editor  which  serves  as  the  user’s  primary  means  for  creating 
and  modifying  documentation. 

3.4.i  fcmrlraniinl 

The  Workbench  provides  an  environment  for  the  documentor 
which  Is  designed  to  make  the  documentat Ion  task  as  easy  as 
possible.  This  encourages  the  documentor  to  maintain  com¬ 
plete  documentation  and  to  keep  this  documentation  up-tc- 
datr.  The  documentor’s  environment  consists  of  tools* 
libraries*  and  documentation  format  standards.  The  basic 
tool  T0r  documentation  Is  the  Text  Editor.  The  libraries 
contain  text  which  can  be  used  durlnq  the  creation  of  new 
documents  and  macros  which  can  be  used  durlno  the  formatting 
stage  to  make  the  documentation  task  simpler  (see  section 
3»t>»2. 1 )  .  The  final  aspect  of  the  documentor’s  environment 
Is  a  set  of  documentation  format  standards  and  aids  to  help 
produce  documentation  fitting  the  standard. 

Figure  3. A.  l-l  depicts  the  Documentation  Preparation  System. 
The  documentor  Interacts  with  the  Text  Editor  to  create  and 
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modify  documents  which  are  maintained  In  various  libraries. 
To  maintain  order  amonq  the  documents*  a  Ooeument  Control 
System  (see  section  3.5)  stands  as  an  Interface  between  the 
Tent  Cdltor  and  the  librarian. 


3.4. l.l  Tool*  and  Libraries 


To  encourage  the  practice  of  good  documentation*  the 
documentor  needs  a  good  set  of  tools.  Chief  among  these 
tools  Is  a  Text  editor  (see  section  3.4.2)  which  allows  the 
user  to  create  and  modify  text  In  an  on-line  fashion.  In 
addition  to  the  Text  Editor.  other  simpler  tools  are  also 
useful.  riamples  of  these  are  a  file  copier*  a  cut  and 
paste  tool*  a  pattern  searching  tool*  a  tool  for  comparing 
the  similarity  of  two  files  and  Identifying  their  dif¬ 
ferences*  etc.  These  tools  are  designed  to  provide  the 
documentor  the  ability  to  Perform  Ms  task  with  the  expen¬ 
diture  of  as  little  time  and  effort  as  possible.  To  meet 
this  goal  the  tools  must  be  staple  to  use.  easy  to  learn* 
flexible*  consistent  with  respect  to  each  other*  have 
default  values  assloned  to  options  which  reflect  the  common 
usage  of  the  ootlons*  and  finally  they  must  naturally  Inter¬ 
face  with  each  other  so  that  several  simple  tools  can  be 
connected  together  to  oerform  comple*  tasks. 
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FIGURE  3.4. 1-1 

PREPARATION  OF  SUPPORTING  DOCUMENTATION 
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The  documentor^  environment  also  Includes  a  series  of 
libraries.  The  libraries  contain  among  other  things  text 
which  may  be  used  By  a  documentor  In  the  construction  of  it 
document.  This  text  can  be  either  other  documental  Ion  or 
proorams.  The  libraries  also  contain  commonly  used  macros 
for  the  Formatter  (see  section  3. 6. 2.1)  which  help  to 
oroduce  standard  formats  of  Items  within  a  document  (e.q.. 
tables,  charts,  lists,  figures,  etc.). 

3*4. 1.2  Documentation  Foreat  Standards 

Another  asoect  of  the  documentor**  environment  Is  a  set  of 
documentation  standards.  These  arc  designed  to  ensure  that 
all  documents  of  a  particular  type  or  belonging  to  a 
oartlcular  organization  use  the  same  set  of  formatting  con¬ 
ventions.  The  definitions  of  the  standards  are  maintained 
In  libraries  and  are  thus  readily  available  for  consultation 
during  the  documentation  preparation  process. 

Since  the  ultimate  goal  of  document  a t 1 c  i  preparation  Is  a 
finished  document,  the  documentor  will  have  to  consider  the 
format  of  the  finished  product  during  the  preparation  stage 
of  the  documentation  process.  Th1s  means  that  the 
documentor  wilt  have  to  Insert  formatting  commands  within 
the  text  In  order  to  produce  the  desired  results  when  the 
text  Is  processed  by  the  Formatting  Program.  These  Imbedded 
formatting  commands  are  also  the  key  to  achieving  standard 
formats  within  the  documentation.  r-y  constructlno  a  set  of 
formatting  macros  (see  section  3. 6. 2.1).  and  storing  them  In 


Georgia  Institute  of  Technology 


COBOL  Workbench 


Section  3  FUNCTIONAL  COMPONENTS  Page  69 

libraries*  one  can  provlae  the  necessary  aids  to  help  the 
documentor  easily  construct  documents  conforming  to  a  set  of 
format  standards* 

This  technique  was  used  to  provide  the  section  headings  In 
this  report*  Five  macros  were  available  thO*  hit  h2*  hi* 
h*)  depending  on  the  level  of  the  section  belnq  written* 
The  parameters  required  by  each  macro  consisted  of  the  sec¬ 
tion  number  and  the  title  for  the  section*  The  macros 
provided  for  the  consistent  spacing  around  the  headlnos  and 
consistent  use  of  under l Inlnq  and  boldfacing* 

3.^.2  Ini  Lilian 

The  Test  Editor  allows  the  documentor  to  create*  updatr*  and 
modify  unformatted  documents  In  an  on-line  manner.  In  ad¬ 
dition*  It  allows  him  to  copy  text  from  one  document  while 
creatlnq  or  editing  another.  Thus*  the  documentor  can  copy 
text  from  other  documents  and  trim  and  modify  the  copied 
text  to  fit  his  needs* 

The  Text  Editor  possesses  a  powerful  set  of  commands  which 
obey  a  slmnle  and  consistent  syntax.  Complex  pattern  match¬ 
ing  Is  also  available  and  allows  matching  patterns  within  a 
line  of  text  as  well  as  locating  lines  contalng  the  pattern. 
Printed  responses  by  the  Editor  are  terse  resulting  In  a 
minimum  of  delay  to  the  user. 
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The  Text  Editor  alto  provides  users  possessing  fast  CPT 
terminals  the  ability  to  view  a  window  of  their  text  while 
edition.  this  Is  a  powerful  feature  which  not  only  aids  the 
user  in  Mndlng  portions  of  te«t  Out  also  makes  the 
construction  a  n  -i  modification  of  text  easier.  In  addition 
to  frtnu  able  to  view  a  xln^o.  of  text,  one  hjt  the  at)  1 1  1 1  } 
to  directly  change  text  displayed  In  the  window.  To  enhance 
this  c  a  V  a  0  1 1 1 1  >  .  the  user  Is  also  given  the  ability  to  posi¬ 
tion  t-c  cursor  to  the  left*  to  the  right*  up*  cown*  or  to  a 
particular  character  on  a  line. 

In  ea'.e  the  user  forgets  one  of  the  simple  commands  of  the 
''alter,  ne  can  ask  the  Editor  for  help.  "cpendlng  upon  how 
the  hr l o  Is  requested*  the  user  will  qet  either  general  In¬ 
formation  r,  ,jt  the  Editor  or  information  about  the  use  cf  a 
particular  command.  The  help  feature  Is  designed  to  provide 
complete  inforsati.n  for  the  beginner  and  specific  Informa¬ 
tion  for  the  more  experienced  user  of  the  Text  Editor. 
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The  development  of  software  systems  Is  an  evolutionary 
process.  Thus*  there  *111  usually  be  Multiple  versions  of  a 
progra*  or  docu*ent  In  existence  s  1*u'  > aneous l y  .  For  exam¬ 
ple*  a  particular  program  say  be  In  production  while  an  up¬ 
dated  release  of  the  sase  progras  Is  In  developaent.  These 
constitute  two  different  versions  of  the  sase  program.  Ir. 
addition  to  these  two  versions  of  the  progra*,  there  will 
also  ne  two  versions  of  the  docusent a 1 1  on  supporting  the 
proqran*.  To  help  Maintain  order  among  multiple  versions  of 
the  same  orogran  or  document*  the  Workbench  provides  a 
Document  Control  System. 

The  eost  promising  strategy  for  providing  document  control 
Is  that  of  maintaining  a  list  of  changes  corresponding  to  a 
particular  revision  of  a  document.  These  changes  will 
reflect  the  differences  between  a  particular  revision  and 
Its  previous  revisions.  A  more  detailed  explanation  of  Ihl* 
technique  can  be  found  In  Appendix  3.  The  revisions  of  all 
documents  will  reside  In  a  set  of  libraries  (see  seeti  * 
3.5.1). 
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^•s*i  LUfiriii 

An  Important  part  of  document  control  Is  Horary  manage ment  • 
As  mentioned  earlier*  there  are  a  number  of  llorarles 
required  to  support  all  the  activities  of  the  Workbench*  and 
a  an  y  of  these  libraries  contain  similar  component  files  or* 
at  least*  component  fltes  that  could  be  applleo  to  the  same 
use  and  might  even  be  Identified  by  the  same  name*  The  two 
Important  aspect*  then  of  library  management  are 

1)  the  management  of  the  contents  of  tor  various 
libraries  In  a  consistent  manner*  and 
21  the  management  of  the  use  of  the  various 
libraries  In  the  support  of  the  various  ac¬ 
tivities  orovlded  by  the  workbench. 

The  various  libraries  In  the  Workbench  and  their  contents 
are  depicted  In  Table  3. 5*1-1*  The  uses  of  these  libraries 
are  listed  In  Table  3*  *3. 1-2* 

3. 5. 1.1  General  Library 

The  General  Library*  GCNLI9*  contains  the  coapHcr- 
Inoeoenoent  test  of  a  collection  of  general-purpose* 
reusable  modules  which  will  be  of  use  to  all  programmers* 
These  nodules  mlqht  Include  the  following: 

-  data  1  nout  editing 

-  file  structure  definition 

-  report  generation 
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WORKBENCH  LIBRARIES  AND  THEIR  CONTENTS 


LIBRARIES 


Definition  of 
Coop  1 ler-UnIqu* 
Func  1 1  on* 


Reusab le 
Module • 


Test 

Hjrntiifi 


Programming 

Skeleton* 


Basel In# 
Progr a«s 


Program  RELEASES 
I  VERSIONS 


No  t  a  t 1  on* l 
Short  and* 


Personal 

Programs 


Breadboard 

Programs 


General 

|  Application 

j  |  Project 
I  I  Release 


|  Personal 
|  ]  Test  C.U. 

|  |  I  Macro 

I  I  I  I 

V _ V _ V _ V _ 


T:  Tested 


0!  In  Development 
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Llferux 


Central 


Appl 1c«t Ion 


Project 


Release 


Ptrtont l 


TABLE  3.5. 1-2 

WORKBENCH  LIBRARIES  AND  THEIR  USES 


U1U 


Supports  work  on  •  large 
number  of  projects  end  ap- 
plication  areas. 

Primarily  to  support  work  In 
a  specific  application  area* 
e.g«*  payroll*  Inventory* 
etc  • 

The  development  files  for  a 
specific  project. 

The  docuaentat Ion  actually 
released  to  users. 

Anything  that  Is  not  ready 
for  public  use*  e.g.*  hat 
not  been  tested  or  Is  not 
Intended  for  public  use. 

Test  harnesses. 

Coaptler  unique  aacrot  which 
are  used  to  replace  macro 
calls  of  COBOL.wbc  In  order 
to  produce  code  for  a  par¬ 
ticular  compiler  (COBOL. k). 


Compiler-Unique  Macro 
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GENU!*  contains  only  tested  code.  Net.  nodule  definitions 
s»ar  be  added  to  GENLlfi  by  Installation  oersonnel  only  after 
complete  testing. 

The  modules  are  written  In  COfiQL.wbc  and  contain  no 
coop  1  ler-dcpendent  references.  These  modules  may  contain 
calls  to  itiicroi  as  well  as  calls  to  other  modules. 

J.l.l.C  Application  Libraries 

The  Application  Libraries  are  special  purpose  module 
libraries  containing  nodule*  developed  for  special  ap¬ 
plication*.  r  * aep  l  e s  light  Include  a  package  of  payroll 
saodulr*  or  n  package  of  module*  developed  tor  Inventory 
control.  f  very  application  will  posses*  Its  own  library. 
IPPLlf’-no’se  <c.g.  APPLtli -PAYROLL  or  Ap!>LIc,-lNVfN).  Ap¬ 
plication  libraries  contain  only  tested  code. 

3.0.1.?.!  iCUidfeiC 

"Oiiulcs  are  used  to  isolate  any  freguently  performed  func¬ 
tion  or  task  In  a  single  piece  of  code,  to  eliminate  rrdt/n« 
dant  coalni  of  such  tasks,  and  to  simplify  maintenance.  The 
modules  Included  In  the  Application  Libraries  are  developed 
specifically  for  a  particular  application  but  may  be  used  by 
other  projects  as  the  occasion  reoulres.  They  are  written 
In  COBOL. woe  and  must  be  both  tested  and  complete. 
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.1.5. 1.2. 2  SL£iM20i 

tested  Programing  Skeletons  which  are  useful  tc  a 
particular  application  and  are  written  In  COBOL.  wt>c  are  kept 
In  the  Application  Library  for  the  particular  application. 
These  skeletons  aay  refer  to  reusable  modules  stored  In 
other  libraries. 

3.5. 1.3  Project  Libraries 

Project  Libraries  contain  reusable  test  harnesses,  propras- 
«1na  skeletons,  baseline  prograas.  and  breadboard  progrees. 
all  of  which  are  developed  specifically  for  a  particular 
programing  project.  The  libraries  are  named  "PHOJLIS-proJ" 
where  "proj"  Is  the  name  of  the  particular  project  which  Is 
served  by  the  library. 

3 . 5 . 1 . 3 . 1  ityiiSLkl  -SL&UiZl 

The  reusable  modules  contained  In  the  Project  Libraries  ser¬ 
ve  the  same  purposes  as  the  reusable  modules  kept  In  the  Ap¬ 
plication  libraries.  They  are  oeveloped  specifically  for  a 
particular  oroject  under  development  and  should  not  be  used 
by  any  other  project  since  the  changlna  needs  of  the 
development  teas  say  modify  module  calling  usaor  or  behavior 
or  eliminate  sc«e  modules  altogether.  The  mooule*  Included 
In  the  Project  Library  are  written  In  COSOL. wbc  and  arc 
tested. 
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3.5,  1*3.2  _r ill  Harnesses 

lest  harnesses  to  be  used  In  the  testing  of  the  nodules  of  a 
particular  project  are  housed  In  that  project*!  Project 
Llorary,  These  modules  are  written  In  C0B0L»wbc  and  have 
ceen  tested, 

3 .  ,  1 .  1 .  J  (ZL2HL^lll0.2  iUl£l2Di 

f'ronroise  1n>j  Skeletons  that  are  applicable  only  to  o 
particular  project  are  kept  In  the  project*!  Project 
Llorary,  They  are  written  In  COBOL.wbc  ana  hove  been 
tested.  They  nay  call  nodules  which  are  housed  In  other 
l Ihrarles, 


3,o,i, 3,4  eaiiiius  fLtaaia* 

The  baseline  oroqr.a*  as  contained  In  the  Project  Library  Is 
a  tested  orogrni,  It  Is  written  In  COBOL, wbc  anc  ray 
contain  calls  to  nodules  developed  especially  for  the 
project  and  maintained  on  the  project  library*  as  well  as 
calls  to  tested  nodules  contained  In  tbr  other  libraries 
descrloed  In  this  section, 

3«5«1«3,5  2tSj&4£2.a!<2 

Breadboard  oroargas  that  are  developed  for  e  particular 
project  are  kept  In  the  Project  Library  for  the  project. 
These  oregrass  are  written  In  COBOL, wbc.  They  have  not  been 
rigorously  tested*  but  are  still  believed  to  be  correct. 
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3.5.1.*  Release  Library 

The  Release  Library  contains  those  programs  which  have  Leon 
released  for  general  use.  This  Includes  tested  Baseline 
°rograss  written  In  COGOL.wbc  ano  the  coao 1 l er-spec 1 f 1 c 
RELEASES  and  VERSIONS  of  the  Baseline  °roqraas  which  arc 
written  In  the  particular  dialect  of  COBOL  (COBOL • * ) 
provided  by  the  target  aachlne  on  which  the  proqraa  Is  to 
run. 


3.5. 1.5  Personal  Libraries 

The  Personal  Libraries  are  used  by  the  programmer  to  store 
any  material  he  Is  developing.  They  contain  code  In 
COBOL. whc  or  COBOL « k  and  will  usually  be  untested.  After  a 
or ogr am  or  nodule  Is  completed  and  has  been  sa 1 1 s f ac t or  1 1 y 
tested*  It  will  normally  be  moved  to  one  of  the  other 
libraries  (e.o.«  General  Library*  Application  Libraries* 
Project  Libraries*  etc.). 

Thr  Individual  programmer  a  ay  choose  tc  make  use  of  the 
Workbench  facilities  to  permit  notatlonal  shorthand  for 
thlnqs  Mkr  long  variable  naaes  or  frequently  occurring 
stateaents.  These  notatlonal  shorthands  are  stored  In  the 
Personal  Libraries.  These  individual  abbrevlat Ions  should 
be  removed  froa  the  completed  code  by  expanding  such  nodule 
calls  Into  the  corresponding  code. 
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j.s.i.fe  Test  Library 


The  Test  Library*  TCSTL10,  consists  ol  test  harnesses  into 
Mhich  the  proirawcr  say  Insert  a  newly  designed  -nodule  for 
test  nurooscsi  routines  for  the  generation  of  rondo*  data 
meeting  specified  format  restrictions*  and  oeneral-purpose 
output  routines.  Other  TCSTlIO  functions  *  'yM  provide  the 
capability  to  collect  performance  data.  '.e  (tortules  are 
orovined  in  orger  to  assist  the  programmer  in  the  develop- 
«cnt  o  *  nc  •<  ff-ortul  cs  • 


TfSTLir  contains  only  tested  code.  New  module  definitions 
or  routines  nay  oe  added  to  USTLIP  by  installation  person¬ 
nel  only  alter  coeptete  testino. 


5.h.l.7  Co«p1l«r-Un1<jue  Macro  Libraries 

The  workbench  contains  a  series  of  libraries*  MfcCLlB.n,  for 
each  target  compiler  n.  These  contain  the  test  for  the 
conp  1  ler-d'-cendent  macro  expansions  for  the  particular  co#- 
p  11 r  r  n. 

The  macro  library  will  serve  as  one  of  the  inputs  to  the 
sacro  expansion  processor  which  will  translate  the  coapller- 
indroendent  proaraa  text  Into  COBOL  code  for  compilation  by 
a  particular  compiler.  Macros  «ay  call  other  macros*  but 
ear  not  call  modules  or  contain  COBOL. wbc  statements  not 
included  in  the  compiler  for  the  given  taroet  machine. 
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The  Macro  Library  contains  the  text  which  the  Macro  Proces¬ 
sor  uses  to  expand  macro  calls  Into  compiler-unique 
notation.  It  Is  necessary  that  strict  naming  conventions  be 
used*  as  each  MACi.IB.1  must  contain  definitions  for  all  of 
the  same  macro  calls.  Oue  to  the  nature  of  this  orocess*  It 
Is  likely  that  the  majority  of  macro  definitions  stored  In 
any  q 1  yen  NACLlO.k  will  be  empty. 

The  necessary  M*CU8s  will  be  provided  along  with  the  Work¬ 
bench  and  should  not  be  modified  by  Installation  personnel. 
MACLIHs  contain  only  tested  code. 

3*5.2  fiflniCfil  ftl  SflUMt  cm* 

within  the  Workbench  environment*  a  single  module  may  be 
maintained  In  a  number  of  different  versions.  The  source 
code  comprising  the  module  may  be  maintained  In  multiple 
copies*  each  Including  (possibly  minor)  changes  from  the 
orlolnal.  This  approach  Is  not  desirable  for  three  major 
reasons. 

1)  c. torage  Is  used  Inefficiently  to  maintain 
multiple  copies  of  (essentially)  duplicate 
Informat  Ion. 

2)  a  programmer  making  a  modification  may  not  be 
modifying  the  latest  version. 

3)  It  Is  very  difficult  to  remove  a  modification 
other  than  the  latest. 

A  better  approach  Is  to  store  the  original  module  source 
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cocfc  only  once  and  to  record  all  modifications  05 
Insertions*  deletions,  or  replacements  to  the  original  file. 
To  simplify  operation  by  avoiding  the  need  for  special  crea¬ 
tion  facilities,  the  ortatnal  module  Source  rite  may  be 
regarded  as  empty,  with  the  first  update  consisting  of  a 
series  of  Insertions.  The  workbench  Source  Control  Facility 
Is  suggested  to  provide  these  features. 


3.5. 2.1  Structure 


* 


Th-  Source  Control  Facility  maintains  a  project’s  source 
code  In  a  number  of  data  files,  h 1 c r a r c h  1  ca 1 1 y  orqanlrea. 
Fach  module  Is  maintained  as  an  Individual  file  which  r.ay  be 
modified  1 ndl v 1 dua l l y .  Larger  program  fragments,  while 
stored  Internally  as  a  collection  of  nodule  source  files, 
may  be  treated  logically  as  a  single  file  and  modified  as  a 
unit.  This  process  of  combination  of  modular  subunits  to 
produce  larger  units  Is  carried  upwards  throughout  the 
project  source  library*  The  PRIMOS  file  system  (see  Appen¬ 
dix  8)  facilitates  the  use  of  this  kind  of  hierarchical 
st  rue  *ure. 
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3. 5. 2. 2  Features 

rcaturcs  0’  the  Source  Control  Facility  Include 

1)  Creation  of  Module  Source  File, 

2)  Updating  of  module  Source  File  by  Inserting, 
ieletlno,  and  restoring  source  tines  accord¬ 
ing  to  Information  stored  In  the  file  or 
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provided  at  part  of  the  correction  set. 

3)  Anility  to  completely  and  permanently  remove 
correction  sets  from  the  “odule  Source  File* 

A)  Generation  o t  a  module  version  corresponding 
to  the  modifications  desired  by  the  program¬ 
mer  and  expressed  In  the  correction  set. 

5)  .Generation  of  a  new*  updated  Module  Source 

File. 

fc)  Comprehensive  listings  noting  ar.y  changes 
made  to  the  "odulc  Source  File*  as  well  as 
the  status  of  alt  source  lines  contained  In 
the  file  (Inserted*  deleted*  modified). 

7)  the  ability  to  group  modules  together  Into 

larger  units  and  to  perform  the  above  tunc* 
t  Ions  on  these  larger  units. 

In  order  to  1»ole*ent  these  features*  It  Is  necessary  to  as¬ 
sign  each  source  line  a  unloue  Identifier. 

3. 5. 2. 3  Status 

The  Source  Control  Facility  Is  not  yet  fully  Implemented? 
however*  the  facility  parallels  a  number  of  commercially 
available  tools*  such  as  COC  *s  programs  UPDATE  and  MODIFY. 

3.5.3  uit£  aa&Ultnll 

Among  the  documents  maintained  by  the  Document  Control 
System  arc  user  documents.  Examples  of  this  group  of 
documentation  are  user  manuals*  reference  manuals*  Instruc- 
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tlons  for  data  preparation  and  entry*  reference  material  to 
support  feedback  fro*  user**  etc* 

3. 5. 3.1  Original  Oocumtnt 

An  original  document  1$  Identified  as  version  one  of  release 
one  of  the  document.  Since  It  Is  the  first  revision  of  the 
document*  the  list  of  ehanges  corresponding  to  It  will 
consist  only  of  Insertions.  Treating  the  orlqlnal  document 
In  this  nanner  will  make  It  consistent  with  the  other 
revl slons. 

3. 5. 3. 2  Released  Modifications 

Modifications  to  a  document  are  obtained  by  creating  new 
VERSIONS  for  a  particular  release  or  creating  a  new  RELCASC 
(see  Floure  1.3-1).  Changes  to  the  baseline  program  result 
In  the  creation  of  a  new  RELEASE  while  changes  to  the 
cordI ler-unloue  VERSIONS  of  the  baseline  program  result  In 
new  VERSIONS.  The  Document  Control  System  provides  the 
ability  to  mark  revisions  at  to  whether  or  not  they  are 
available  for  release.  In  addition*  the  user  can  upon 
request  obtain  a  list  of  those  revisions  approved  for 
release • 
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3*5*3*3  Latest  Version  of  s  Release 

The  Document  Control  System  allows  one  to  obtain  any  VERSION 
of  any  RELEASE  by  simply  specifying  the  specific  version 
number  and  release  number*  Users  can  also  obtain  the  latest 
VERSION  of  a  RELEASE  by  ataply  specifying  the  desired 
release  or  the  latest  RELEASE  by  specifying  the  name  of  the 
document • 


3. 5. 3. s  Maintaining  Coeaants  on  Oocuaants 

To  obtain  a  document  which  Is  correct  and  satisfies  the 
needs  of  the  user  community*  a  means  of  obtaining  feedback 
fro*  the  user  co*«un1ty  *ust  be  available*  This  service  It 
provided  *1th  the  help  of  the  Oocu«ent  Control  System.  User 
comments*  which  *ay  be  either  note*  on  oosstble  errors  or 
suggestions  for  changes  to  a  document*  are  dated*  Identified 
by  the  user  making  the  comment*  and  linked  to  the  document 
to  which  the  coament  refers*  The  one  responsible  for  the 
document  can  obtain  the  comments  from  the  Document  Control 
System*  act  upon  them*  and  reply  to  the  originator  of  the 
comment • 


3. 5*3. 5  Working  Oocuaants 

Documents  In  the  working  state  can  be  Identified  as  such  by 
the  one  responsible  for  the  document*  The  Document  Control 
System  will  then  be  able  to  detect  that  the  document  Is  a 
working  document  and  will  not  give  that  document  to  a  user 
requesting  a  released  document* 
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3.5.4  Biflifllltni  BatuitoU 


Management  documents  are  Maintained  by  the  Document  Control 


Systea  In  the  tame  manner  at  uter  documents,  example*  of 


thl*  group  of  document*  are  per*onnel/team  orgonliatlon  and 


task  breakdown*  project  buagets*  cost  and  time  performance* 


project  ttatus*  test  plans*  etc. 


3*5.4. 1  Original  Requirement* 


Among  the  documents  maintained  by  Document  Control  are  those 


specifying  the  requirements  for  the  software  systems.  The 


original  requirements  for  a  system  are  found  In  version  one 


of  release  one  of  the  document  containing  the  requl rements. 


3. 5. 4. 2  Current  Requirements 


As  the  requirements  for  ft  system  change*  the  document 


containing  these  requirements  will  evolve  new  versions  and 


possibly  new  releases.  To  obtain  the  latest  requirements* 


one  need  only  specify  the  name  of  the  document  containing 


the  requirements  and  the  Document  Control  System  will  obtain 


the  correct  release  and  version.  It  should  be  noted  that 


the  treatment  of  these  documents  Is  the  saee  as  the  user 


documents  mentioned  above. 
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3.5. 4.3  Change  Requests 

Change  requests  received  free  either  users  or  the  proponent 
organization  for  whom  the  «*stem  was  designed  are  reviewed 
by  the  project  management  staff  and  then  entered  Into  the 
documentation  data  base  so  that  they  will  be  available  for 
consideration  when  the  neit  major  release  of  the  program  Is 
prepared. 

3.5.4.*  Approved  Modifications 

Based  upon  change  requests  from  users  or  based  upon  changes 
In  the  functions  that  must  be  provided  by  the  data  proces¬ 
sing  system*  the  proponent  or  the  proponent  organization  or 
"owner"  of  the  syste*  In  consultation  with  the  developing 


organlzat Ion 

will 

review 

and 

approve 

modlf Icatlons  to  be 

made  to 

the 

system 

the 

nest 

time  a 

major 

release  It 

orepored. 

These 

modi  fleet  Ions 

will 

be  stored 

In  the 

document  at  Ion 

data 

base 

approDrlately 

l Inked 

to 

those 

port  Ions 

to 

which 

they 

apply 

so  that  they 

are 

readily 

available  and  apparent  to  the  project  team  when  the  new 
release  Is  preoared. 

3.5.*.5  Maintaining  Coaaents  on  Oocuaents 

The  technique  for  maintaining  comments  on  management 
documents  Is  Identical  to  that  for  user  documents  (see  sec¬ 
tion  3.5.3.*). 
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3. 5. a, b  Working  Documents 

The  techniouea  used  to  handle  working  management  documents 
Is  Identical  to  that  for  user  documents  (see  section  3.5*3). 

3. 5.4. 7  Project  Status  end  Control 

Since  the  Document  Control  System  maintains  all  revisions  of 
all  documents  and  all  comments  pertaining  to  those 
revisions*  one  should  be  able  to  easily  obtain  the  stAtus  of 
a  project.  Since  the  Document  Control  System  possesses  the 
necessary  Information  to  report  on  the  status  of  a  project* 
It  Is  responsible  for  providing  this  service.  The  user  need 
only  specify  the  documents  to  be  analysed*  and  the  Document 
Control  System  will  provide  Information  Indicating  the 
revisions  available  and  the  change  reaues'es  which  have  been 
acted  upon. 
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3*4.1  Smarm  Pr.aflmllaQ 

Program  production  It  a  function  provided  by  the  COBOL  com¬ 
piler  and  programing  system  applicable  to  the  target  en¬ 
vironment.  The  Workbench  toolt  provide  the  capability  to 
produce  a  co*p1  ler-unlque  VERSION  of  a  baseline  program 
RELEASEt  however*  the  only  dialect  of  COBOL  that  can  be 
translated  Into  an  object  program  by  the  Workbench  Is 
COBOL. wbc. 

3.4.2  Oatmipiiiiflo  gcaamtlao 

To  produce  printed  documentation*  the  documentor  must  direct 
the  Test  Formatter  and  the  detlred  prlntlnq  tools.  The  test 
to  be  formatted  Is  obtained  via  the  chain  fro*  Document 
Control  to  the  librarian  to  the  libraries  and  passed  along 
through  the  Formatter  and  printing  tools  to  the  device  which 
Is  to  print  the  documentation. 

3.6.2. i  Test  Formatter 

Oocuments  In  their  finished  forms  are  obtained  by  running 
them  through  the  Test  Formatter.  This  formats  the  test  ac¬ 
cording  to  commands  Intermingled  with  the  test  and  default 
settings  for  those  options  not  specified  by  commands.  The 
Test  Formatter  allows  the  user  to  make  either  the  left  or 
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FIGURE  3.4. 2-1 
DOCUMENTATION  PRODUCTION 
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right  margin  even*  control  the  size  of  the  left  and  right 
nargins  as  welt  as  the  too  and  bottom  margins*  and  specify 
headers  or  footers  to  be  printed  on  each  page  along  with 
numbering  of  the  page*  The  user  can  control  the  line  spac¬ 
ing  and  specify  the  centering  of  specific  lines*  In  ad¬ 
dition*  soecific  words  or  phrases  can  be  highlighted  oy  bol¬ 
dfacing  or  uotfer 

The  ability  to  define  and  use  macros  is  also  available  in 
the  Test  Formatter.  This  includes  the  ability  to  pass 
parameters  when  calling  a  macro*  This  capability  gives  one 
the  ability  to  orcvide  a  set  of  standards  to  a  group  of 
documentors*  This  is  done  by  creating  macros  to  perform  the 
operations  which  are  to  be  made  standard  and  providing  these 
macros  to  the  documentors  through  specific  libraries* 

Thus*  the  Text  Formatter  provides  neatly  formatted  output 
from  very  unstructured  input*  By  delaying  formatting  to  a 
later  stage*  one  Is  able  to  enjoy  e  considerable  amount  of 
flexibility  during  the  entering  and  modification  stages  of 
document  preparation*  This  allows  a  document  to  grow  and 
change  with  a  minimum  of  effort* 

3.6 *2*2  Printing  Tools 

In  addition  to  the  test  formatter*  ether  toots  directed 
specifically  at  the  production  of  printed  material  are 
needed  in  order  to  produce  documentation*  Among  these  are 
tools  to  select  the  range  of  pages  and  number  of  copies  of 
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|  the  ^document  to  be  printed.  The  document*  nay  be  printed  on 

a  variety  of  device*  Including  line  printer*  and  hard  copy 

| 

terminals#  Thuit  there  *ust  be  tools  to  take  the  output 

I 

i  !ro«  the  text  formatter  and  convert  It  to  a  for*  appropriate 

for  the  device  on  which  It  Is  to  be  printed.  For  example* 
document*  to  be  printed  on  a  1 tne  printer  need  to  convert 
all  back  space*  Into  *eporate  line  output*  with  a  form* 
control  that  doc*  not  advance  the  paper.  Thc*e  tools  must 
Interface  with  the  other  tool*  available  on  the  workbench. 
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SECTION  4 

UTILIZATION  OP  THE  COBOL  PROGRAMMER'S  WORKBENCH 


*•1  filttUAk 


A*  It  perhaps  evident  fro*  Section  3*  the  'Workbench  conlsts 
of  only  a  ten  "general -pur pose"  toolt  that  are  utilized  In 
"specialized*  ways  to  provide  the  capabilities  outlined  In 
Section  2.  This  flexibility  Is  provided  by  the  very  power¬ 
ful  and  versatile  Co**and  Interpreter  that  controls  the 
ooeratlon  of  the  Georgia  Tech  Software  Tools  Subsystem. 

The  paragraphs  below  are  not  neant  to  be  a  user  wanual  for 
the  Workbench.  Rather*  they  provide  some  Insight  Into  how 
the  systen  can  be  utilized  to  provide  the  capabilities 
desired. 
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The  variety  of  option*  that  are  possible  In  the  use  of  the 
Program  Preparation  Subsystem  are  alaost  limitless*  The 
paragraphs  below  provide  some  examples  of  typical  or 
representative  uses  of  the  capabilities  of  the  Workbench* 

4.2.i  eiadMtiflfl  a  um  8 adult  at  Ecaacu 

In  the  simplest  situation,  the  Workbench  Is  used  to  produce 
code  for  a  particular  compiler  k.  (Note  that  It  Is  not 
necessary  that  k  be  a  COBOL  compiler.) 

FIGURE  4.2. 1-1 

PRODUCTION  OF  A  PROGRAM  IN  COBOL.k 
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*•2*2  Pciaacloa  a  BtunfaU  nadult 

A"  reusable  module  Is  prepared  very  similarly  to  any  other 
code  module.  The  critical  aspect  of  a  reusable  nodule  Is 
Its  Interface  to  other  modules.  The  oroductlon  of  a 
reusable  module  differs  from  the  production  of  a  complete 
system  primarily  In  that  the  Interface  behaviour  must  be 
clearly  and  exactly  defined  and  must  meet  the  standards 
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established  for  reusable  Modules*  Use  of  the  standards  en¬ 
forcer  Is  required  for  consistency  between  nodules  developed 
by  different  programmers*  New  modules  should  be  transferred 
from  the  proqram»er«s  personal  library  to  the  project 
library  only  after  passing  the  standards  enforcer  and  under¬ 
going  thorough  testing*  Modules  developed  by  the  project 
should  be  added  to  the  application  library  or  other  general- 
access  libraries  only  after  complete  test*  Once  a  module 
has  been  transferred  to  a  permanent  library*  any  further 
modification  must  maintain  Interface  behaviour* 


FIGURE  9. 2.2-1 

PRODUCTION  OF  REUSABLE  NOOJLES  AND  THEIR  DOCUMENTATION 
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Documentation  should  be  produced  In  parallel*  and  shoulo 
Include  Information  about  the  status  of  testing  and  a  record 
of  any  subsequent  modifications  performed  or  requested. 
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The  Workbench  stay  also  be  used  to  produce  ££MHfel£  code  for 
a  aaiiituUn  coup  Her  k. 


FIGURC  4. 2. 2-2 

PRODUCTION  OF  REUSABLE  NODULES  IN  COBOL. k 
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4.2.3  P£flflU&lQ2  A  AAl&LtSl  SEAAIAl 

Perhaps  the  «ost  Important  factor  In  the  preparation  of  a 
baseline  or ogran  Is  that  the  resultant  COBOL. wbc  progra* 
eust  be  transportable  to  all  of  the  target  operating  en¬ 
vironments  of  Interest.  The  esact  sequence  of  steps  to  be 
followed  ana  the  depth  of  nesting  of  calls  to  code  nodules 
i nd/or  reusable  aodules  Is  reolly  a  natter  of  personal 
oronraeeln j  style.  The  Workbench  will  support  almost  any 
technique  possible. 


The  basic  for®  of  the  baseline  program  that  Is  retained  for 
•alntenance  can  contain  references  to  reusable  modules  that 
Arc  available  for  public  use  (defined  In  the  projects  ap¬ 
plication*  or  general  libraries). 
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There  au*t  he  a  complete  macro  library  prepared  for  each 


target  operating  environment  whether  they  are  distinguished 


by  hardware*  software*  or  other  differences.  As  can  be  seen 


fro*  the  example  In  Appendix  2*  aacro  libraries  can  become 


quite  lengthy  since  they  each  must  contain  a  macro  deflnl 


tlon  for  every  envlronmentally-unlque  feature  even  If  that 


uniqueness  applies  to  only  one  environment*  As  can  be  seen 


fro*  the  example*  macro  statements  can  be  utilized  to  acco*- 


pllsh  several  actions 


.election  of  one  (or  more)  of  several 


statements  In  the  original  program  based  on 


the  name  of  the  target  environment. 


2 )  Expansion  of  a  statement  In  the  original 


program  which  may  pass  parameters  to  the 


mac  ro. 


3)  Elimination  of  a  statement  In  the  original 


orogram. 


4)  Do  nothing  (copy  the  original  statement). 


FIGURE  4. 2.4-1 


PREPARATION  OF  COMPILER-UNIQUE  MACROS 
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It  can  be  iten  from  Figure  4. 2. 4-1  that  It  1*  anticipated 
that  a  system*  programmer  will  he  required  to  prepare 
coop  Uer-unlaue  macros* 


4.2.5  Producing  a  SUULLM 

A  Sreadboard  Program  Is  prepared  In  a  manner  similar  to  any 
other  program  or  nodule  with  two  exceptions: 

U  ’’he  emohasls  Is  on  preparing  a  tlXfil&iXflS. 
program  providing  a  tiftlt  >gtt£ft&l3aliac  to 
systea  f ufle 1 1  one 1 1 1 y  desired*  not  on  meeting 
all  user  requirements  or  on  performance  and 
«f f 1 c 1 ency  . 

2)  The  breadboard  program  Is  not  meant  to  be 
portable  to  a  number  of  operating  en- 
v  1  roneent  s . 

As  a  result  of  the  two  factors  cited  above*  the  developer  of 
a  breadboard  program  *111  make  much  heavier  use  of  reusable 
modules  even  If  they  do  not  provide  exactly  the  detailed 
functionality  desired  and  even  If  they  are  compi ler-unlouc. 
The  steps  In  the  preparation  and  processing  of  a  breadboard 
program  are  basically  the  same  as  those  reguired  for  a 
baseline  program. 
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<•2**  Bilatiiotoa  Hit  Bmilnt  ggoof 


A*  noted  above*  the  baseline  program  Is  prepared  utilizing 
anil  COBOL. wbc  which  contains  statements  that  act  as  macro 
calls  to  handle  compiler-unique  features  and  reusable  Module 
•statements"  which  are  also  expanded  using  a  macro  call 
orocedure.  It  Is  Important  that  the  baseline  orogra*  retain 
these  features  In  order  to  Maintain  Its  Integrity.  Any 
changes  or  Modifications  to  the  baseline  program  must  fellow 
these  sane  standards. 


Maintenance  of  the  baseline  program  Is  usually  performed  for 

*> 

one  of  two  purposes: 

1>  To  modify  or  Increase  the  functionality  of 
the  system  at  directed  by  the  system 
oroponrnts*  or 

To  correct  errors  In  the  program  resulting 


2  ) 


from  loolcal  errors  In  the  design  of  the 
baseline  orogram  or  "mechanical*  errors 
caused  by  the  expansion  and/or  transportation 
phases  of  program  processing. 


The  first  situation  Is  a  fairly  standard  situation  and 
merely  reaulres  reworking  the  code  In  the  baseline  program? 
however*  the  latter  circumstance*  which  will  certainty  occur 
quite  frequently  In  a  dynamic  world  of  changing  target  en¬ 
vironments*  modifications  of  target  system  software*  etc.* 
will  necessitate  changes  In  the  definitions  of  the  reusable 
module  and  compl ler-unlaue  macro  libraries. 
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There  1*  actually  no  need  to  maintain  a  program  RELEASE 
other  than  the  activities  described  above  for  the 
maintenance  of  tne  baseline  Program.  Kowevert  there  will  be 
continual  maintenance  on  compiler-unique  VIRS10NS  of  the 
orogrn*  to  provide  Immediate  correction  of  errors  In  the 
design  of  the  proaram  as  well  at  in  Itt  automatic  processing 
by  the  Workbench.  Such  changes  will  be  made  directly  on  the 
distribution  VERSION  of  the  program  In  COBOL. k  and  will 
produce  MODIFICATIONS  of  VERSIONS. 

*.2.8  SUItill 

The  best  summary  possible  is  a  figure  relating  the  various 
activities  described  above,  this  Information  Is  provided  In 
FI  cure  s*2.*-l. 


Georgia  Institute  of  Technology 


COBOL  Workbench 


Section  4 


UTILIZATION 


Page  101 


FIGURE  4*2. 8-1 

UTILIZATION  OF  THE  COBOL  PR08RANNER*$  WORKBENCH 
(Notes  on  following  pages) 
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Definitions  of  Various  Code  Modules 

Reusable  Nodule* 

written  In  COBOL.wbc  (or.  possibly  In  special 
Instances*  CQBOL.k).  Hoy  contain  references 
to  other  reusable  nodules  and/or  compiler 
unlaue  features  In  COBOL.wbc. 

Compiler-Unique  Macros 

’•'aero  definitions  that  provide  the  Informa¬ 
tion  rcoulred  to  translate  references  to  corn- 
oiler  unique  feature*  Into  fully  expanded 
compiler  unique  code. 

Compiler-Unique  Program  VERSION 

Contains  no  references  to  reusable  modules  or 
compiler  unique  features.  Has  been  processed 
so  that  It  Is  a  source  program  written 
entirely  In  CQBOL.k  iready  for  processing  by 
compiler  ■k"  on  target  machine  K). 

Baseline  Program 

Written  In  COBOL.wbc.  Contains  references  to 
compiler-unique  features  and  reusable  modules 
(written  In  COBOL.wbc). 

Breadboard  Program 


written 

in  COBOL.wbc  (or* 

In  spe 

clal. 

Instances 

*  COBOL.k).  flakes 

heavy  use 

Of 

reusable 

modules  written  In 

COBOL. wbc 

(or 

COBOL. k>. 

If  no  compiler 

exists 

for 
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COBOL •  *bc •  the  breadboard  program  can  be 
processed  to  produce  a  B*k"  version  for 
esecutlon  of  the  prototype  system. 

UsXsli  lac.  Cisuit 

1)  May  contain  references  to  Workbench  Reusable 
Modules  and/or  coispller-untque  features. 

2)  May  also  contain  references  to  Personal 

Reusable  Modules* 

3)  Processes  and  removes  references  to  Personal 
Reusidlc  Modules* 

4)  Processes  and  removes  references  to  Project 
Reusable  Modules* 

5)  Processes  and  removes  references  to  Applica¬ 
tion  Reusable  Modules* 

6)  Processes  and  removes  references  to  General 
Reusable  Modules* 

7)  A  copy  of  the  Baseline  Program  -ill  S£i 
ttflliia  ItltCtntti  la  tax  Reusable  Modules. 
All  such  calls  have  been  expanded  fully  Into 
COBOL *woc.  It  may  still  contain  references 
to  comoller-unlaue  features* 

A)  Processes  and  removes  references  to  compiler- 
unique  features* 
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4.3. X  ZLZU&lt  fl£lalDii  OftiUitaU 

The  preparation  of  original  documents  Is  accomplished  by 
means  of  the  Text  Editor#  Text  can  be  either  entered  direc¬ 
tly  or  copied  from  other  documents  which  already  exist 
within  the  system*  Possible  sources  for  copies  Include  both 
prooram  code  ana  text  documents.  The  documentor  will 
normally  only  wish  to  copy  parts  of  o  program  or  a  text 
document •  This  Is  accomplished  by  first  copying  the  entire 
document  and  then  deleting  those  portions  which  arc  not 
desired.  Since  these  operations  ore  all  carried  out  by  the 
Text  Editor,  one  can  easily  trim  and  modify  the  copied  text 
to  suit  the  needs  of  the  document  being  created. 

*•3.2  Badllxlna  Qfituiioli 

The  modification  of  documentation  Is  also  realized  through 
the  text  Editor.  The  operations  available  to  the  documentor 
Include  insertion,  deletion,  and  modification  of  text.  In 
addition*  the  documentor  can  copy.  trim,  and  modify  text 
from  any  desired  source. 
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♦•3.3  Aoofltiiloa  Qaiuitaii 


It  <s  extremely  likely  that  after  a  proorae  or  text  document 
has  ?fen  released  for  general  use  that  an  error  will  **e 
discovered  or  a  place  for  improvement  will  be  noticed.  !f 
one  wishes  to  point  out  an  error  or  make  a  suggestion  for 
improvement*  one  need  only  access  the  annotating  feature  of 
the  wor*:Dench*  specify  the  document  of  Interest*  inducing 
the  release  and  version  numbers*  an*  specify  the  corment 
concerning  the  document*  The  Workbench  will  appeno  to  th«> 
document  the  name  of  the  user  generating  the  comment  and 
will  then  link  this  collection  of  information  to  the  proper 
document*  Those  responsible  for  the  docunent  will  he  able 
to  obtain  the  list  of  comments  pertaining  to  any  document* 
act  udoh  these  comments*  and  respond  to  those  identified  as 
responsible  for  the  comment. 


The  flnnotat  ina  capability  need  not  only  be  usee,  on  prooraft 
and  documentation  released  for  general  use*  It  can  also  be 
used  by  the  development  croups  to  aid  in  coordinat inn  all 
parts  of  a  large  system* 


4.3.4  eradut-lM  SatUXli  milaoi 


Specific  versions  of  documentat ion  can  be  maintained  and 
produced  through  the  document  control  facilities  of  the 
'workbench*  Documentation  is  organized  according  to  a 
release  nurbrr  and  o  version  number  within  a  release*  To 
create  a  new  version  of  a  release*  one  must  obtain  the 
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latest  version  of  the  document  from  Document  Control.  Any 
changes*  additions*  and  deletions  can  then  be  made  to  this 
document  by  means  of  the  Text  Editor.  when  all  of  the 
modifications  have  oeen  made*  Document  Control  is  called 
uoon  to  build  a  n<x  version.  If  a  new  release  is  to  be 
constructed*  one  must  obtain  the  latest  version  of  the 
latest  release  ana  oroceeri  as  described  above.  Finally*  if 
t hv*  first  version  of  the  first  release  of  a  oocument  is  to 
be  produced*  one  need  only  build  the  document  with  the  Text 
Editor  and  inform  Document  Control  that  the  first  version  of 
the  first  release  is  to  be  built,  further  details  concern¬ 
ing  "ocueent  Control  can  be  found  in  Aoocndix  J. 
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FIGURE  4,4-1 

TESTING  A  COBOL. wbc  MODULE 
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4.4,1  Macma&b  Ini  flatcallao 


4.4,1, l  Input  to  the  Testing  Process 


1)  COBOL, wbc  Source  Module 


The  testlno  process  wilt  convert  tho 
COBOL, wee  nodule  Into  successive  COBOL. 1 
nodules  and  test  each  neither  of  the  resultlnc 
family  o *  modules. 


2)  ?*  ACL  I  *3 . 1  *  where  1  goes  from  1  to  n 
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'.'c  cess  ary  to  permit  conversion  of  the 
CODOL'.voc  nodule  into  the  corresponding 
CGS20L.1  modules# 

3)  Special  Instructions  (Modules  provided  on 
’tSTL ISt 

-  In  establish  the  test  en- 
v i ronnent . 

lo  control  the  test  scouencim. 
etc. 

-  Io  create  test  data  acetlno  oata 
declaration  regut  resent s . 

-  To  create  test  files  meeting  the 
file  forsot  socc i f  icat ions  of  a 
niven  rachlne. 

Output  fro*  the  Testing  Process 

1)  .useric  values  fros  test  runs. 

•••eon.?  the  special  Instructions  Included  on 
TcSTun  xUl  oe  routines  to  print  both  the 
random  data  aenerstod  os  Input  and  the 
results  of  the  test  runs.. 

2)  diagnostic  Inforsatlon. 

Anong  the  special  Instructions  Included  on 
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If  STL  IB  wilt  oe  routines  to  col  lc*c  t  per¬ 
formance  data  and  to  trace  e.ecutlon  of 
modules  under  test. 

4.4.2  saiLiili  Ini  fimfrlllllti 

1>  \cceut  the  COBOL.wbc  Source  Module*. 

It  Is  strongly  reconmerded  that  only  thos>? 
nodules  which  have  passed  Standards  enfor¬ 
cer  .woe  oe  accepted  us  Input.  This  nay  he 
achieved  automatically,  hy  calling  the  stan¬ 
dards  enforcer  as  the  first  step  In  the  test¬ 
ing  process.  or  manually.  by  reouestlna 
project  programmer*  to  submit  only  approved 
nodules  for  testing. 

2)  Js1n*j  test  harnesses  (modules)  provided  on 
TrSTLIS*  produce  an  e^c<;gtable  COBOL. wbc 
program • 

What  we  mean  by  a  test  harness  Is  a  main 
program,  espressed  In  the  form  of  a  module, 
which  serves  os  a  driver  to  e*ecute  an  other¬ 
wise  Incomplete  COBOL.woc  module.  Specific 
capabilities  and  requlrenents  of  test  harnes¬ 
ses  will  be  discussed  In  a  later  section. 


3)  Translate  the  resulting  COBOL.wbc  program 
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into  COBOL. k. 

At  the  ronent  we  /take  no  attempt  to  execute 
f OBCL • wbc •  Whit-*  it  toy  in  fact  he  possible 
to  do  so.  and  thus  to  test  COHCL.wbc  orooraas 
directly  without  conversion  into  specific 
dialects.  this  approach  leads  us  into  a  very 
complex  problem  area  which  is  beyond  the 
scope  of  this  project,  namely  the  problem  of 
verification.  If  we  arc  to  draw  any  useful 
conclusions  froa  our  testing  of  a  •“OBOL.wht 
orocrao  we  must  be  aole  to  verify  that  a 
particular  COBOL.*  program  is  functionally 
Identical  to  the  criminal  COBOL. wbc  pro gram. 
All  that  we  are  able  to  show  without  dispute 
is  that  a  particular  COBOL. k  urogram  was 
derived  <1.e«*  :>.s  a  macro  expansion)  from  the 
original  COBOL. wbc  program.  This  Is  net  suf¬ 
ficient  to  demonstrate  correctness. 

M  Generate  test  data. 

•hat  we  want  here  are  a  set  of  routines  to 
Generate  random  data  meetlno  a  given  data 
»pec M Icat Ion.  These  routines 

-  could  be  Implemented  In  ony 
language  (need  not  be  written  In 
COBOL) 
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-  couto  t'r  Implemented  either  as 
nodules  (If  written  In  COPOL.ubc  > 
or  as  separate  routines  (In  which 
case  there  would  be  at  leant  one 
routine  for  each  COBOL. 1) 

-  would  be  stored  In  TESTL1 

-  accept  as  Input  COPOl.ubc  data 
declaration  divisions 

-  produce  as  output  random  rota 
neetlno  the  Input  data  declara¬ 
tion  and  the  file  structure 
requirements  of  the  given  target 
•such  Inc 


b)  r*erdse  the  proqraa  logic. 

In  other  worus.  execute  the  COBOL.  1  program, 
developed  In  step*  2  ond  3  above  using  the 
rando*  data  <ron  step  *  as  Input.  l>  trace 
routine  to  ensure  that  every  logic  branch  In 
trleo  night  be  useful  here.  Another  useful 
iporoacb  would  be  to  rake  use  of  the  Idea  of 
program  "isutants"  to  ensure  that  toe  test 
cases  generated  by  step  -  represent  an 
ibeouatc  test  of  the  program  logic. 


fe>  Derive  statistics  on  performance  of  the 
module  being  tested. 
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TCSTLIii  includes  COBOL.whc  modules  designed 


1 or  the  collection  of  perlonunce  data.  The 


tppropri<ite  nodules  are  selected  and  calleo 


tnacro  calls)  hy  the  test  harness.  Per- 


*  or nanc  e  data  which  might  oo  collected 


i re l uoe  s 


-  CpU  tie"  used 


-  *.<1n  memory  used 


-  oaglnti 


-  number  of  Iterations 


71  Jepe.it  steos  3-6  above  for  each  coroi.t  as 


1  oo**s  from  1  to  n. 
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SECTION  5 

IMPLEMENTATION  OP  THE  DEMONSTRATION  WORKBENCH 

An  Important  qoal  of  t h  1  *  research  project  was  empirical 
-tuoles  of  the  concept  of  the  COBOL  Programmer •»  Workbench 
and  thr  Implementation  Issues  Involved.  There  have  been  a 
large  number  of  proposals  to  achieve  oroyra*  portability* 
however*  very  little  of  this  work  has  been  reduced  to  prac¬ 
tice.  It  was  felt  essential  that  a  practical  cenonstratlon 
of  at  least  the  general  concepts  be  Included  In  this 
research  project.  Althouqh  It  was  not  possible  to  construct 
a  complete  version  of  the  workbench*  It  Is  felt  that  the 
Demonstration  workbench  that  was  produced  clearly 
demonstrates  the  feasibility  of  the  concepts  and  Ideas 
Drejented  as  well  as  highlights  the  problems  that  must  oe 
addressed  In  the  development  of  a  complete  workbench  systen. 

s.i  mu  &£  iirnm  Mamtata 


fh«/re  were  four  basic  objectives  for  the  development  of  the 
demonstration  rQBGL  Prooraismer’s  Workbench.  These  four  were 

1>  Feasibility  demons t ra 1 1  on  of  the  operation 
concepts  proposed. 

2)  I  pent  1 f 1  cat  Ion  of  the  major  problems  that 
would  be  encountered  In  the  Implement  at  Ion  of 
a  complete  Workbench. 

2)  investigation  of  the  desirable  features  of  a 
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user  environment  for  the  Workbench. 

4)  estimation  of  the  value  of  the  concept*  of 
reusable  program.  modules  and  maintenance  of  a 
slngte  OAsc-llne  prouram  for  multiple  target 
machines. 

What  was  attempted  was  a  balance  approach  toward  making  sone 
progress  In  rcachlno  all  o*  these  ooals.  It  was  recognized 
that  It  would  not  be  oosslbte  to  Implement  a  complete  ver¬ 
sion  of  the  COBOL  I’roorammer’s  Workbench  with  the  time  and 
resources  available  nor  dlo  the  research  team  feel  that  It 
hao  sufficient  Information  to  allow  It  to  embark  on  a  com- 
oletr  development  project.  It  was  felt  that  the  effort 
could  be  much  core  usefully  applleo  to  laying  solid  ground 
work  on  which  a  further  project  aimed  at  the  complete  work- 
ocncn  Implementation  could  be  based. 
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5*2  mm  otmamai  m  mu  miuau 

The  research  team  was  fortunate  In  hawing  avallaolc  for  this 
project  an  extremely  powerful  hardware  and  software  en¬ 
vironment  on  which  to  Implement  the  Demonstration  Workbench* 
The  computing  system*  a  Prim.*  400*  Is  one  of  the  "large*  or 
"mega"  mini  <  'aputers  which  rivals  mainframe  systems  as  large 
as  the  IBM  System  370/150  and  168  for  computational  Dower* 
A  further  advantage  of  this  specific  computer  system  w.*s  the 
extremely  large  virtual  aodress  space  available*  (However* 
there  were  limitations  on  the  sl/e  of  object  programs  that 
could  be  generated  by  the  versions  of  tne  l OBOL  compiler 
that  were  available  during  the  early  phases  of  the  project*) 
The  hardware*  however*  provides  only  a  portion  of  the  er- 
v  1  rorisnnt  In  which  the  Demonstration  workbench  was 
est  tbl Ished. 

The  research  systems  environment  available  was  also  greatly 
enhanced  by  having  available  on  the  Prime  4C0  system  the 
Georgia  Tech  Software  Tools  Subsvsten  CKernlchan  19763,  The 
Georgia  Tech  Software  Tools  Subsystem*  which  Is  described 
briefly  below  and  In  more  detail  In  the  appendix*  provides 
not  only  an  extremely  hospitable  environment  for  the  users 
but  also  an  extremely  powerful  environment  for  the  construc¬ 
tion  of  command  files  that  support  the  use  of  tne  subsystem 
comoonents  In  the  Implementation  of  the  Demonstration  Work¬ 
bench*  The  availability  of  the  Georgia  Tech  Software  Toots 
Subsystem  was  invaluable  In  expediting  the  development  of 
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the  Oeronst rat  Ion  Workbench. 


5*2*1  PlllLC  Ail  CMftUllI  Sllltl 


The  Prime  400  computer  system  Is  a  fairly  recently 
Introduced  system  (  1976)  t h a t  falls  Into  the  category  of  the 
large  or  aega-ninicomputer  sUe*  The  Prtme  40Q  shows  strong 
Influences  of  the  ^ultics  System  In  both  Us  hardware  anti 
software.  It  Is  an  extremely  powerful  minicomputer  provid¬ 
ing  an  excellent  environment  for  software  development 
projects  such  as  this. 


5. 2.1.1  Hardware 

The  ^rtre  4  00  Is  of  the  large  mini  or  mcoa-alnl  class  cf 
corouters.  It  possesses  a  powerful  processor*  large  main 
memory  *  largo  virtual  memory*  ond  can  handle  uo  to  6 S  users. 
Shared  code  facilities  and  o  multi-ring  protection  mcchonlsm 
are  also  provided.  The  Prime  400  uses  microprogrammed  logic 
and  possesses  a  writable  control  store. 


5*2*1.  1*1  li££flr  ^ 

T h"  Prime  *00  prcyldes  both  a  larae  real  and  virtual  memory. 
The  maximum  siic  of  Physical  memory  Is  o  million  bytes.  It 
Is  Incrementally  expandable  by  ?56K  byte  boards*  In  audi¬ 
tion  to  main  memory*  a  high  speed*  bioolar  cache  memory  of 
2K  bytes  Is  provided* 
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ylrtuul  memory  Is  provided  In  terms  of  paging  and  seg¬ 
mentation*  The  maximum  size  of  virtual  memory  Is  SIP  mil¬ 
lion  bytes*  but  each  user  program  Is  limited  to  3?  million 
bytes.  The  page  size  Is  10  24  bytes »  the  segment  size  is 
12BK  bytes*  and  the  maximum  number  of  segments  Is  ‘♦096* 

S. 2. 1*1.2  liiaiiifiELi 

The  Prime  400  has  12B  program  addressable  32-bit  registers. 
Of  these.  4  are  used  as  oase  registers.  2  arc  used  as  float- 
in-  point  accumulators,  and  2  are  used  as  field  address  and 
length  registers.  The  remalnlno  registers  are  used  to 
control  DM4  channels  and  hold  the  machine  states  of  active 
orocesses • 

5. 2. i.i.3  imUaUiaQ  kzt  iiatiinACi:  Suaaatl 

The  Prime  *00  hardware  provides  a  32-blt  arithmetic  logic 
unit  and  32-blt  and  64-hit  Integer  arithmetic,  ft  floating 
point  unit  Is  orovloed  oy  means  of  microcode.  The  following 
Is  a  list  of  some  of  the  Instruction  groups  and  how  they  arc 
Implemented: 

decimal  arithmetic 
Inteoer  arithmetic 
floating  point 
charactei  string 
conditional  branches 
log1c.il  operations 
1  oolca t  test  and  set 
program  control  and  Jump 


emulat Ion 

hardware 

microcode 

emulat Ion 

hardware 

hardware 

hardware 

hardware 
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queue  mnoaqement  microcode 

shifts  and  skips  hardware 

data  move  hardware 

5. 2. 1.1. 4  Prams*  i*fih»na£  fitiklL* 

The  Dr1<-c  <>00  process  exchange  facility  Is  provided  through 
firmware  that  automatically  dispatches  tasks  for  execution 
and  reorders  those  which  remain.  This  Is  accomplished  with 
no  software  1 nt ervent 1  on.  The  process  exchange  facility 
also  automatically  handles  the  register  switching  that  is 
needed  as  a  result  of  a  process  exchange. 

5. 2. 1.1. 5 

To  -  types  of  access  modes  for  I/O  are  available? 


1 ) 

Mrect 

Memory 

Access  C DM t ) 

2) 

llrect 

-c*ory 

Channe t  s 

(OMC> 

3) 

1 1  rcct 

Memory 

T  r ons  f o  r 

(DMT ) 

9 ) 

'  1  rec  t 

Memory 

Gucue  (DM0) 

There  arc  a  maximum  of  32  program  assignable  OMA  channels. 
These  -re  controlled  by  high  soccd  channel  address 
reolsters.  They  ore  used  for  high  speed  peripherals  such  as 
fast  disk  fevlces.  The  maximum  transfer  rate  Is  2.b  million 
bytes  oer  second. 

The  OMC  channels  are  controlled  by  channel  address  words  in 
the  first  *1K  bytes  of  main  memory.  Uo  to  2‘J*»S  of  these 
channels  can  oe  provided.  Their  use  Is  mainly  for  medium 
soeeo  i/O  transfers  such  as  data  communications  transfers. 
The  maximum  transfer  rate  Is  960k  bytes  per  second. 
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The  UWT  channels  are  used  oy  high  speed  device  controllers* 

i 

e.p.*  controllers  for  moving  head  disks*  that  execute  chan¬ 
nel  control  oroaraxit.  The  maximum  throuqhput  rate  Is  2»'l 
million  bytes  oer  second. 

The  OFG  mole  of  operation  provides  a  circular  gucuc  for  han- 
dllnq  communication  devices.  It  reduces  operating  system 
overhead  by  eliminating  Interrupt  handling  on  a  character- 
by-character  basis. 

5. 2. 1.1. 6  laxlraeissiii 

Programs  on  the  Prime  *C0  ooerate  in  a  mul t 1 -segment  en¬ 
vironment.  This  consists  of  a  stack  segment  for  local 
variables*  a  procedure  segment*  and  a  linkage  segment  for 
statically  allocated  variables  and  linkages  to  common  data. 
Stack  management  Is  provided  by  means  of  nardware.  and 
procedure  calls  are  managed  by  microcode. 

5.2. 1.2  Standard  System  Software 

The  Standard  °r1ne  AGO  Systems  Software  of  Interest  In  this 
project  Is  the  PRIMOS  Ooeratlno  System*  the  PRIv-0S  File 
System*  and  the  Prime  noPOL  Programming  System. 

5.2. 1.2.1  I he  fii^raiinn  nIfiicm 

The  occratln.i  system  for  the  pr1me  *00  conputer  system* 

PRI^OS*  orovldes  interactive*  batch*  and  real-time  super- 

/• 

visory  services  within  a  single  system.  It  can  handle  up  to 
6 i  concurrent  processes  including  Interactive  users  at  local 
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or  remote  terminals*  phantom  users*  and  RJL  processes*  The 
Prime  AOfl  system  contains  a  segmented  and  caned  virtual 
memory  with  a  5?  megabyte  address  space  and  uo  to 
megabytes  of  main  memory.  In  addition*  3  2K-bytc  bipolar 
cache  memory  is  utilized.  PR! *>05  can  maintain  a  oisl 
capacity  etceeoing  2. *  billion  oytes. 

is  embedded  in  the  virtual  adnress  spaces  of  all 
processes.  This  results  in  providing  access  to  any  operat¬ 
ing  system  resource  in  the  same  amount  of  time  as  it  takes  a 
user  process  to  call  a  subroutine.  The  multiple  ring 
protection  system  ensures  that  this  feature  docs  not  result 
in  the  operation  system  being  modified  by  the  users. 

The  allocation  of  CPU  time  is  provided  by  means  of  time 
slices*  normally  1/3  second.  Time  slices  are  allocated  on  a 
priority  i>@s1s  with  highly  interactive  processes  receiving 
relatively  high  priorities  and  processor-bound  processes  oe- 
ina  given  lower  priorities. 

To  minimize  paoino*  multiple  processes  ore  able  to  use 
identical  ooqes  of  a  shared  procedure  segment.  These  shared 
procedures  are  reentrant  and  thus  remain  unaltered  by  the 
processes  that  use  them.  A  shareo  procedure  exists  only 
once  on  disk  and*  when  active*  only  once  in  main  memory 
regardless  of  the  number  of  processes  using  it. 
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Process  exchange  Is  handled  bv  a  hardware  dispatcher 
(microcode)  which  manages  the  Seaoy  List*  a  number  of  Walt 
Lists*  Semaphores*  nnl  the  Process  Control  Blocks.  a 
process  exchange  Is  caused  asynchronously  oy  haruwam 
generated  Interrupts*  faults*  ana  checks*  and  It  Is  cause? 
synchronously  by  a  process  executing  cither  the  WHT  or 
NOTIFY  Instructions.  The  dispatcher  also  nanaocs  the 
processor’s  live  registers  so  that  sets  of  the  registers  can 
be  assigned  to  different  processes*  and  thus  the  nocc  to 
save  and  restore  register  contents  Is  reouced.  The  Ready 
List  Identifies  alt  processes  which  are  ready  to  run  ,md  Is 
ordered  by  priorities  and  then  chronologically.  Semaphores 
are  associated  with  each  event  that  cjn  cans**  an  exenang". 
They  occupy  two  words  of  storage.  One  word  contains  Mther 
a  counter  which  Indicates  how  raor.y  times  an  event  has  oc¬ 
curred  without  being  serviced  by  a  process  or  the  number  of 
processes  waiting  for  an  event  deoendlno  on  the  sign  of  the 
numoer.  The  second  word  contains  a  pointer  to  a  :Jalt  List 
of  processes  waiting  for  the  event. 


The  virtual  address  space  Is  organized  as  multiple  segments 
each  with  slsty-four  (6<t)  2*<-bytc  oeges.  A  virtual  <*.7drcss 
consists  of  a  scomcnt  number*  *  page  number*  and  a  word  or 
displacement  number,  a  physical  address  can  be  obtained  by 
means  o  *  segment  tables  and  Page  mops  which  arc  maintained 
In  main  memory.  The  system  uses  demand  paging  with  the  LRU 
reolacement  scheme.  To  speed  access  to  memory  there  Is  a 
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segment  table  lookaside  buffer  which  holds  physical  page  ad¬ 
dresses  and-  a  bloh  speed  cache  memory  which  contains  the 
most  recent  memory  references*  To  satisfy  a  memory 
reference#  the  cache  memory  Is  addressed  on  the  basis  of  the 
word  number  of  the  virtual  address  and  th**  segment  table 
lookaside  buffer  Is  consulted  to  determine  If  the  worn  ob¬ 
tained  from  the  cache  Is  the  desired  one* 

5#e. 1.2.2  £££21* 

COBOL  on  the  °r1«e  A00  system  Is  based  on  the  ANSI  COBOL 
standard.  Programs  up  to  S3  million  bytes  can  be 
supported.  All  ANSI  *7*  COPQL  files  organized  as  INDEXED  or 
RELA1 i VT  arc  established  as  MICAS  (Multiple  Index  lata  Acr 
cess  S  y  s  t  *r  )  files*  a  'HOAR  file  can  oe  accessed  »y  mul¬ 
tiple  users  In  a  seoucntlal  or  random  manner  and  can  have 
locks  specified  at  the  data  record  level  to  resolve 
Concurrent  usaoe  conflicts*  Up  to  si*  keys  or  key  synonyms 
can  oe  used  to  perform  a  oortlal  file  search* 


Prime  COBOL  implements#  to  a  minimum  of  level  1#  the 
nucleus?  table  handling*  seoucntlal#  relative  and  Indexed 
I/O;  library;  and  Int erprooran  comnun i cat  Ions  nodules*  The 
dc  u;  -ooule  Is  Implemented  with  the  f.EACY  7AACC#  RESET 
TR’-CE#  and  EXHIBIT  NAVf  features  supported  In  the  procedure 
division*  The  level  ?  features  which  arc  Implemented  are 
the  following; 

1)  STR INC /UNSTRING  statements. 

"onditional  expressions; 

-i)  Conjunctive  operators  (and*  or#  not)* 
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:?)  Relational  operators  <=»  ;>«  <*  not  =  • 

not  >♦  not  <>. 

f )  cull  parenthesis  support* 

d)  Implied  subjects  and  re l a t 1 onsh 1 ps • 

e)  (Jested  IF-  statements* 

I)  OPEN  with  EXTEND. 

A)  INSPECT  statement, 

b)  ALTER  statement. 

6)  COHP-3  pack  decimal. 

7)  COMPUTE  with  multiple  receiving  Melds, 

fi)  PERFORM  VARYING  with  index. 

*? >  SEARCH  statement. 

10)  ALTERNATE  RECORD  KEYS  WITH  DUPLICATES  lor  IN- 
"'E VE 0  Hies. 

II)  A  s-'rles  or  range  of  values  In  level  38  con- 
fit  Ion. 


5. 2. 1.2.3  Th*  PRJM£S  fU£  System 

The  PRIMOS  operatin')  system  for  the  Prime  A00  computer  sup¬ 
ports  as  one  of  Its  services  a  flexible*  hierarchical  file 
system  that  provides  users  with  the  facility  to  maintain 
large  Quantities  of  data  in  an  orderly*  loolcal  manner.  a 
brief  overview  of  the  file  systems  capabilities  and 
features  Is  provided  In  Appendix  fc.  it  is  somewhat  tutorial 
in  nature  md  does  not  attempt  to  cover  all  of  the  available 
features*  nor  to  present  the  details  of  Implementation* 
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5..'t.2.l  General 

Th<  Sut's/steff  consists  o f  a  co*»frfln*J  interpreter  that  sup¬ 
ports  easy  interconnoc  t  ion  of  orocraas.  a  laroe  collection 
of  software  tools.  and  the  capability  for  developing 
cus  1 0*  i  /  ed  toots#  It  runs  as  a  collection  of  user  oroeraits 
uni er  standard  versions  of  the  PHJvOS  IV  and  V  operating 
syst*"*s»  thus  ret. inina  all  security  provided  by  PR1"0S  as 
well  is  allo»in«‘  users  to  ignore  the  Sus.syste*  if  they  so 
oecirr#  tven  so.  toe  lubsystr*  is  sufficiently  com¬ 
prehensive  to  oemit  use  of  the  co*cuter  without  a  working 
know  l  cine  ^  *  pKI',0<-# 


The  concepts  used  in  the  ^utsystc*  are  oerived  trot,  the  tent 
SflliiliilLSi  l2£li  f  "erninhon  7  f»  3  •  The  Georgia  Tech  Software 
Tools  Tub  system,  however.  nos  undergone  development  that  has 
ore.it  l  y  extended  it  beyond  the  starting  point  given  by  the 
nook#  for  instance,  the  Text  fditor  hat  been  expanded  into 
a  ful l -screen  OnT  editor.  ano  tnc  coe*an1  language  hat 
occo'c  a  superset  of  that  provided  by  th^  CM*  operating 
system# 


-•*.?.  v-nat 
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5.?. 2.?  *«for  Components  and  Future* 


The  najor  f s*ooficnH  Anc  features  of  the  Subsystem  are  «is 
f  oi l  oms  : 


1)  lo^nonc  Language 

«>  onlfpr®  Invocation  of  Commands 

:>)  dynamic  Command  Line  Structures 

c  )  Comaanc  Piles 

i>  Control  Structures 

o )  Scoped  variables 

f)  Networks  of  Cooperating  ‘'roc rantt' 

?>  “otfer  ("Rational  FORTRAN"  -  a  Preprocessor ) 
*)  Modern  Control  Structures 

p )  cree  Format  source  Code 

c)  ‘Taste  Macro  “apabllltv 

*>  Long  variable  Nones 

e  >  Cebugglnr  and  Performance  Monitoring 

i )  f  v % t  Cdltor 

l)  Pull-Screcn  version 

<»)  1 1ne-0r  lent ed 

c)  In-line  editing  Capability 

1)  Sin  liar  to  ‘J‘i  I*  Test  Editor 

a)  Teit  For^ottf-r 

>>  Autos at  1c  Hynnef at  Ion 

t  )  Macros 

c )  In-Line  f  unc  1 1  or  s 

t! )  Clvers Ions 

r>  Number  Registers 

0)  On-line  Cocyrcnt at  Ion 

a;  Access  to  Reference  Manual 

n )  Short  Usage  Su»*ary  Available 

S>  <s sorted  Tools 

a?  ?1rectnry  <*  a  Intenant  *• 

:■  >  Ureas  Cutting  and  Selection 

c>  Sort  and  Comparison 

d)  Spelling  Check 
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5*3  Q&i&MWMH.  ft£  Hit  QEMomsisaiiqh  hdbkbemch 

Conceptually  the  or  :an i zat ion  of  the  'je*>onst  rat  ion  vorktench 
is  quite  5  Innlc.  it  consists  of  the  fottowinq  major  co<r- 
p  o  n  e  n  t  s  t 

1)  The  P°  1  dC  *00  Conputer  Oyster- 

A  )  The  i  ■'OS  Operatino  System 

3)  'he  'more l a  Tech  Software  Tools  Subsystem 
)  *  collection  of  .a  ft  ware  Tools  coneaiv)  files 

The  last  component  above  transforms  the  total  environment 
from  a  general  purpose  support  environment  into  a  system 
which  will  provide  the  specific  capabilities  nf  the  COBOL 
>‘ro«r«*K>er's  ^ork*'cnch«  In  this  specific  «rca«  the  real 
power  of  the  Software  Tools  Subsystem  proved  invatuaole  to 
t  hn  pro'ect  tea** 

A  casual  or  non- sy  s  1 1  ms  programmer  user  of  the  vort^-ench 
aoc s  not  noed  to  ter  l he  individual  components  listed  above* 
It  is  also  highly  unlinely  in  normal  use  that  a  casual  user 
would  need  to  examine  or  understand  the  contents  of  the  con- 
nanr  files  or  their  operation.  One  of  the  extrr«ely  useful 
features  of  the  'oftwarc  Tools  Subsystem  is  the  ability  to 
treft  executable  command  files  in  the  same  manner  as  any 
other  file*  and  1*  the  user  slttfno  at  u 1 s  terminal  enters 
the  nme  of  that  file*  then  It  will  be  iutosat 1  cal l y 
executed.  tMs  allows  us  to  define  and  utilize  estremelv 
simple  and  meaningful  command  names  for  utilisation  by  the 
COBOL  orojraamcr.  it  is  also  the  extreme  flexibility 
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provided  oy  the  corcaand  interpreter  that  provides  an  en¬ 
vironment  that  wilt  react  to  any  style  of  proora.T.ming 
desired  t>y  the  orogra««ier. 


(ieor.|1ej  Institute  of  Technology 


COBOL  workbench 


■  %  .  ■>  •  a  .  3  ,r*  < .  , 

-  ,  »5*V N.  ,*/  *»  4*  .  f.  jw  ''A^rVfeV^'  v  < ,  r' 


-v  ,  •  -'*!*,  '  •'*  * 

''  _  yr  -  *  V  ' 


Section  5 


UtMMk  WViWWxHWrtVt  <rv<«K«w  XMl 


IMPLEMENT  AT  ION 


Page  1?H 


5^  fiEil&AIlfta  2E  lilt 


WORKBENCH 


Simplicity  of  operation  by  the  user  has  seen  one  of  the 
primary  oolectlves  In  the  design  of  the  workbench*  This  Is 
one  area  In  which  we  feel  that  the  research  project  has  been 
entrenety  successful* 

As  mentioned  above*  t*e  workbench  user  Invokes  t  h«*  service 
desired  by  merely  glvlno  a  single  name  command  to  the  com¬ 
mand  Interpreter  Interface,  rowever*  at  the  came  time*  the 
programmer  Is  at  It*  to  change  or  modify  the  standard  opera¬ 
tion  of  the  workbench  by  oulldlng  personal  1  yea  command  tiles 
or  en'.crlnj  single  more  primitive  commands  to  the  command 
Interface* 

en  •  ef  the  r  r  1 1  ,j  r  y  foundations  for  this  tle«tbH1ty  Is  the 
s  t  i  o  t  a  rn  'He  structure  for  all  files  create  n  oy  the  » o  r  k  - 


bench,  ^eiaroless  of  whether 


file 


created  and/or 


mo 'If  tec  ty  a  command  file  operation  or  ey  Individual 
So  f  *  w  i  re  7  oo l s  commands*  It  retains  Its  standard  or- 


n  in  1 /at  Ion* 


ina 


therefore  can  be  easily  Integrated* 


concat Inated*  or  operated  on  with  other  fltes  In  a  uniform 
aannt*  r  • 
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a im  im  tafiauaicsEa 

There  were  actually  only  two  major  problems  encountered  dur¬ 
ing  this  project  and*  unfortunately*  neither  one  has  been 
solved  completely.  One  of  these  major  problems  pertains  to 
Program  Preparation*  while  the  other  concerns  the  documenta¬ 
tion  Subsystem. 

The  concepts  of  the  Program  Preparation  Subsystem  have  been 
Implemented  and  amply  demonstrated  for  both  their  power  and 
usefulness.  The  major  Impediments  to  comoletelno  an 
operational  model  of  the  programming  suosystem  are! 

-  The  definition  of  Workbench  COBOL  (COBOL.wbc) 

-  Tne  definition  of  the  COBOL  Programmer**  En¬ 
vironment 

COBOL  programmers «  as  a  oroup*  have  been  very  slow  to 
utilize  automatic  programming  aids*  even  those  rudimentary 
ones  presently  available  to  them.  During  the  course  of  this 
study*  extensive  conversations  have  been  held  with  key  per¬ 
sonnel  In  several  large  COBOL  programming  groups.  In  almost 
all  of  these  meetings  the  same  conclusions  were  reached. 
Since  COBOL  programmers  have  had  so  little  exposure  to 
automated  software  tools*  they  are  not  able  to  provide  any 
definitive  quldance  as  to  what  would  be  useful  for  them  or 
even  what  they  would  like  to  have  available.  On  the  other 
hand*  all  of  these  programmers  Admit  that  there  Is  a  high 
potential  for  Increased  productivity  If  such  tools  were 
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available.  It  appears  that  the  only  approach  that  Is  going 
to  work  In  solving  this  problem  Is  to  develop  some  specific 
COBOL  pro  trammer *s  environment  Including  specialized  tools 
such  .is  customized  screen  editors.  copy  -  f  rom-l  1  tirar  y 
capabilities.  program* Ino  skeletons.  f  II l -  1 n- 1 yt l ank s 
technloucs.  etc.,  and  to  try  out  these  specialized  tools 
with  COBOL  oroaraemers  In  an  operation  environment. 

As  has  been  well  argued  earlier  In  this  report,  there  Is  no 
desire  to  design  a  new  language  for  the  use  of  programmers 
preparing  transportable  COBOL  programs.  Rather,  what  Is 
desired  Is  o  language  that  Is  as  close  as  possible  to  stan¬ 
dard  COBOL  with  deviations  being  made  only  to  accomodate 
those  absolutely  essential  requirements  necessary  for 
oortabllty*  Our  studies  during  this  project,  however.  In¬ 
dicate  that  It  does  not  anneor  feasable  to  Include  the 
entire  COBOL  standard  In  Workbench  COBOL.  It  does  not  ap¬ 
pear  to  us  that  such  an  extensive  lanquuge  Is  at  oil  neces¬ 
sary.  The  real  goal  In  the  design  of  Workbench  COBOL  Is  t.o 
provide  a  language  powerful  enough  and  rich  enough  so  that 
experienced  COBOL  progr amsers  can  easily  and  efficiently  1m- 
olemcn):  operational  COBOL  data  orocesslno  systems.  There 
have  been  a  number  of  studies  prepared  on  the  development  of 
portable  COBOL  subsets.  However.  It  should  be  emphasized 
that  that  Is  not  the  approach  belno  taken  he  re.  What  Is  be¬ 
ing  done  here  Is  preparing  a  "complete"  COBOL  language  where 
those  features  that  have  to  be  tailored  to  a  specific 
cor.pller-unlouc  environment  are  handled  by  the  prooram 
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processors  In  the  Workbench.  The  Initial  studies  that  hove 
been  performed  In  obtaining  this  goal  have  focused  on 
Identifying  what  features  of  COBOL  arc  utilized  by  program¬ 
mers  In  the  execution  of  their  task*  It  apears  that  this  is 
a  valid  approach  to  this  problem*  and  all  that  remains  to  be 
done  Is  to  utilize  a  broaaer  sample  of  programs  and  applica¬ 
tion  areas  in  order  to  ootaln  high  confidence  In  the 
validity  for  the  design  of  Workbench  COBOL* 

The  last  major  problem  are n  that  was  not  completely  solved 
durlnq  this  research  project  was  the  selection  of  a  method 
to  store  and  produce  various  versions  of  a  document  that  Is 
undergoing  continual  change  and  revision.  The  basic  ap¬ 
proaches  to  this  problem  are  described  In  Appendix  3.  This 
Is  another  area  In  which  It  appears  that  more  detailed 
knowledge  of  the  environment  in  which  the  system  Is  to  be 
utilized  will  be  required  before  a  specific  implementation 
technloue  can  oe  selected. 
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SECTION  6 
SUMMARY 

T  h  i research  project  has  been  successful  in  achieving  Its 
goals  in  the  study  ono  development  of  the  COBOL  Programmer's 
Workbench.  The  concept  of  the  workbench  and  the 
capabilities  it  provides  have  been  shown  to  be  quite  valid* 
and  the  Oemonst rat  ion  Workbench  clearly  illustrates  the 
feasibility  of  implementing  a  complete*  full-scale  COBOL 
Programmer's  Workbench.  The  Workbench  similarly  supports 
the  oevelooncnt  of  breadboard*  prototype  systems,  however* 
it  should  r-e  noted  that  investigation  of  the  value  and 
feasibility  of  the  use  of  preadboarq  systems  was  not  within 
the  scope  of  this  project. 

Althouoh  the  conccot  and  feasibility  of  the  Workbench  have 
been  verified*  a  larae  amount  of  work  remains  to  be  done 
before  a  complete  Workbench  could  be  implemnterf.  The  major 
areas  in  which  work  Is  still  required  are 

-  Completion  of  the  definition  of  Workbench  COBOL 

-  Completion  of  the  definition  and  design  of  the 
C030L  programmer's  environment 

-  Selection  and  leplementat ion  cf  the  technique  to 
be  utilized  to  maintain  and  generate  various 
versions  of  documentation. 

One1  of  the  requirements  necessary  to  support  this  further 
work  is  access  to  several  major  programming  teams  and 
cooperation  from  those  teams  in  obtaining  actual  usage  data 
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APPL IB-name !  A  library  file  containing  macro  definitions 
(In  CQPOL.whc)  of  utility  routines  and  modules  coireonly 
needed  In  a  particular  application  area.  Typical  exam¬ 
ples  Include  APPtn-PAYROLL  and  AP°L  IB-INVLN. 

Bate  Line  Systea:  The  COBOL.wbc  proornn  that  defines  the 
djXU/ered  COflOL.n  programs  for  the  various  target 
machines. 

Breadboard!  *'•  progra<n  developed  primarily  as  an  ex¬ 
perimental  model  of  a  production  prooram.  ras1ly 
nodlflaolc  to  permit  both  requirements  changes  and 
eventual  optimization. 

CSee  prototype] 

Capability!  A  tasx*  purpose*  or  function  which  mav  be 
carried  out  In  some  unspecified  manner  by  a  lannuage  or 
system.  An  example  of  a  capability  In  OBOL  Is  the 
ability  to  sort  files  according  to  the  value  of  a  given 
field!  this  might  be  performed  by  the  use  of  a  SORT 
verb*  py  a  call  to  an  external  procedure*  or  by  the  in¬ 
line  Inclusion  of  the  appropriate  COBOL  commands. 

COBOL  Programmer**  Workbench!  A  comprehensive  collection  of 
caoabllltles  and  facilities  to  assist  the  COBOL 
programmer  In  the  development  and  preparation  of  com- 
olete  COBOL  systems  'iupoorted  by  full  documentation. 
Other  capabilities  of  the  workbench  are  to  facilitate 
the  oevclooment  of  "prototype  or  breadboard"  COBOL 
orojriat  from  a  collection  of  reusable  COBOL  modules 
ana  to  facilitate  the  preparation  of  COBOL  programs 
that  nay  be  easily  converted  to  a  number  of  different 
target  machines  each  having  its  own  unioue  dialect  of 
the  COBOL  language. 

CSee  program  preparation  system!  text  documentation 
preparation;  document  control  system] 

COBOL. CCS!  Common  COBOL  Subset.  This  consists  of  those 
elements  of  C030L  common  to  all  COBOL  compilers. 
COBOL. ecs  ‘s  not,  sufficient  for  the  development  of 
useful  i > ogroms.  COBOL.ccs  Is  Included  in  both 
C0B0L.deso  and  COBOL.wbc.  COBOL.ccs  Is  a  proper  subset 
of  COBOL. 

COBOL. demo!  The  Initial  approximation  to  COBOL.:';*.  As 
COBOL. demo  is  excected  to  approach  COBOL • w&c  aver  time* 
distinction  is  made  between  the  two  languages  only  when 
necessary  for  a  clear  understating  of  the  difference 
between  what  shgul^  be  included  (COBOL*wbc)  and  what  it 
has  been  able  to  implement  thus  far  (CGBOL.demo ) • 
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Eventually.  COBOL. demo  and  COBOL.wbc  wilt  become 
Identical.  Note  that  COBOL. demo  It  not  a  proper  subset 
of  standard  COBOL! 

COBOL. i:  defers  to  any  member  of  the  oroup  of  COBOL 
dlilects  occcpted  by  target  machines. 

C  Set  COBOL.wbc  t  COBOL.k! 

COBOL. 1  Program:  A  compiler-  (and  machine*-)  dependent  C030L 
program.  Refers  to  any  member  of  the  family  of 
program!:  defined  by  a  particular  COBOL.wbc  program. 

CSee  COBOL.k  program! 

COBOL. kt  The  dialect  of  COBOL  associated  with  a  given  COBOL 
compiler  k.  Programs  written  In  COBOL.k  may  not  run  on 
a  different  COBOL  compiler  without  modification  since 
the  dialect  may  contain  compiler-dependent  features. 
[Set  COBOL. wbcl  COBOL. 13 

COBOL.k  Program:  A  program  written  In  COBOL.k.  A  non¬ 

portable  pregram. 

CSee  COBOL.wbc  program! 

COBOL.wbc:  A  lanouage  for  the  development  of  porthole  COBOL 

programs.  This  consists  of  COBOL. ccs  plus  a  collection 
of  macro  calls  giving  the  programmer  the  ability  to  ex¬ 
press  comp  1 1 er-deoendent  features  In  a  compiler- 
independent  manner.  The  Workbench  expo nos  COBOL .woe 
Into  the  COBOL.k  of  a  target  compiler  k.  Note  that 
COBOL.wbc  Is  na^  a  proper  subset  of  standard  COBOL! 

CSee  COBOL. II  COBOL.k!  COBOL. demo!  f See  also  Appendix 
2!  Appendix  7;  Appendix  ?! 

COBOL.wbc  Module:  A  macro  which  expands  Into  COBOL.wbc  cooe 
defining  a  commonly  occurring  function  or  action.  This 
permits  the  programmer  to  develop  £C.U44tlC  sections  of 
code.  COBOL.wbc  module  definitions  are  Included  In  the 
following  libraries:  GENLIB.  APPLIB-name*  PROJLIB- 

nare*  TESTLIB. 

COBOL.wbc  Program:  A  program  written  In  COBOL.wbc.  A 

program  which  can  be  easily  transported.  Consists  of 
COBOL. ccs  statements,  module  calls,  and  macro  calls. 

Compiler-Dependent,:  written  In  a  particular  COBOL  dialect 
for  compilation  by  a  qlven  compiler.  Cannot  neces¬ 
sarily  be  compiled  by  a  compiler  written  tor  a  dif¬ 
ferent  dialect.  It  Is  possible  for  a  program  to  be 
compiler-dependent  while  belno  each Ine- Independent ♦ 

CSe*  nonportable!'  aachtne-dependent I  COBOL.k!  dialect! 

Compiler-Independent:  written  without  reliance  on  language 
features  unloue  to  a  given  COBOL  dialect.  Can  oe 
transported  easily.  Usually  designed  with  portability 
as  a  sajor  goal.  ><ust  be  machine-independent • 

CSee  portable!  machine-independent t  C0B0L.wbc3 
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Conversion:  The  modification  of  a  program  written  In  one 

CAROL  dialect  for  execution  on  r-  machine  accepting  a 
different  COBOL  dialect. 

CSee  portable!  COBOL.wbc! 

Delivered  Program:  Tne  COBOL. k  program  as  It  will  run  on 

the  target  machine  k  In  a  oroductlon  environment.  The* 
program  as  Intended  for  uir  t>v  the  customer  or  other 
ena  user.  At  this  point  the  program  specifications  are 
ft.ed  until  the  original  COBOL. wbt  program  is  aodlfiec 
amt  no*  COhOL.k  code  In  delivered. 

CSee  revision! 

Dialect:  the  particular  CORQl  syntax  rcaulred  by  &  clven 

COhOL  compiler.  Also.  those  language  features  sup¬ 
ported  by  that  compiler. 

CSee  COBOL. k|  COBOL. vbel  «e chine-dependent  l  cospller- 
dependent ! 

Oocueent  Control  System:  Maintains  each  program  and  each 
revision  gr  version  thereof,  as  well  at  any  related 
text  documents,  online  in  an  easily  accessible  and 
easily  modifiable  form. 

Clement:  a  c ha eac t er 1 st 1 c  of  the  language  as  defined  by  the 

137A  COBOL  Standard. 

Feature:  A  charac terl st ic  of  the  language  as  Implemented  by 

a  compiler  on  a  specific  oachine. 

Functional  Testing:  Testing  to  show  the  functional 

eguiv'ience  of  each  of  the  family  of  COBOL. 1  modules  or 
progra-s  derived  from  a  particular  COBOL.wbc  module  (r 
prop Pea. 

CSee  version!  prograc  family! 

OEkSLlB:  A  library  file  containing  macro  definition!  which 

define  utility  functions  and  modules  of  general  use.  a 
typical  module  which  might  fee  included  mere  would  bb  an 
abbreviation  of  the  orogram-io  section.  such  os 
nrovi'-ed  by  hCTa-COBOL.  Should  contain  only  t £ j£ f 9 
r.icro  definitions  written  in  CCBOL.wbc. 

"Helo*  toaaandt  .n-linc  documentation  provided  for  the 
Workbench  user  in  the  form  of  a  guided  tutorial. 

Machine-Dependent :  written  using  hardware  and  operating 

system  features  unions  to  a  particular  nachlne.  Cannot 
be  executed  on  a  machine  with  different  features, 
'esessarlly  coapl ler-dependf nt  as  well  due  to  the  need 
for  the  compiler  to  allow  access  to  the  hardware  and 
operating  system  features. 

CSee  nonportable!  co»pi ler-dependent I  COBOL. M  dialect! 
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Machine  Environment!  The  comb  1  a  t Ion  of  hardware  and 

software  features  flncludlng  hardware  c apao  1 l 1 1  Its  * 
operating  syste*  features*  and  compiler  dialect)  which 
define  the  environment  under  which  a  urogram  Is  to  be 
run.  In  particular*  those  features  which  differ  from 
machine  to  machine*  compiler  to  compiler,  and  Installa¬ 
tion  to  Installation*  and  make  program  transportation 
difficult. 

Machine-Independent :  written  without  reliance  on  hardware 

or  operating  system  features  unique  to  a  given  machine. 
Can  oe  transported  easily  unless  the  prooram  Is 

compiler-dependent. 

CSee  portable!  coapl ler-lndependent I  COBOL. wbc 3 

MACLIB.k:  A  library  file  containing  those  macro  definitions 

which  MACRO  needs  at  Input  In  order  to  convert 
COBOL. wbc  Into  COBOL. k.  (Hacro  calls  must  meet  stan¬ 
dards  so  that  a  given  macro  will  be  called  the  sane  way 
by  COBOL. k  and  COBCL.J.)  Should  contain  only  t  gjtftfl 

macro  definitions. 

Macro!  <  I n  general  usr  tf*e  term  Is  used  to  refer  to 
assembly-level  programming.  However*  It  may  be  applied 
to  higher  level  language  programming*  as  It  Is  used 

here)  A  skeleton  for  an  open  subroutine  which  Is  com¬ 
pleted  by  a  macro  gene r»  tor  In  response  to  a  call  by  a 
macro  Instruction  during  the  process  of  assembling  a 
program.  The  completed  subroutine  Is  passed  to  the  as¬ 
sembler  for  Incorporat Ion  Into  the  program.  However* 
the  term  may  also  apply  to  higher  level  language 
programming.  A  program  unit  which  performs  a  single 
function  and  is  expressed  In  a  reusable  form.  Similar 
to  a  subroutine*  although  a  macro  Is  a  purely 

device  which  Is  expanded  In-Hoy  Hike  a 
Fortran  statement  function)  to  produce  the  appropriate 
code  each  llffi  It  Is  called  while  a  subroutine  call 
produces  only  a  Jump  to  a  single  copy  of  the  required 
cede  regardless  of  the  number  of  calls  to  the 
subrout Ine. 

CSee  module!  CSee  also  Appendix  7] 

Macro  Processor:  t  prooram  which  accepts  as  Its  Inputs  text 
containing  macro  calls  and  a  file  containing  macro 
definition*  and  produces  as  Its  output  text  In  which 
the  macro  calls  have  been  expanded  Into  their  related 
def  In  1 1 1  on* » 

CSee  macro!  module)  CSee  also  Appendix  7) 

Maintenance:  The  changes  necessary  to  keep  a  delivered 

program  executing  correctly  according  to  the  original 
specifications  despite  discovery  of  errors  and  changes 
In  machine  environment. 

CSee  modification) 
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Modlf  Icatlon:  The  change*  ner,e**ary  to  change  the  specified 
behavior  of  a  delivered  program* 

CSee  ■alntenancel  revision] 

Module!  A  program  unit  which  perform*  a  *1ngle  function  ano 
Is  expressed  In  a  reusable  fore  *0  that  the  same  code 
may  be  used  to  perform  the  cane  function  wherever  It 
appears  In  the  sane  proprai  or  other  programs*  Written 
In  COGOL.wbc. 

(See  macro] 

Module  Interface:  The  standard*  governing  module  call*  and 
1nterrel3t Ions  between  the  segments  resulting  from 
modular  expansion  Into  the  COPOL.-oc  program*  For  the 
purposes  o 1  the  Workbench#  all  modules  are  expressed  at 
macros  and  module  usage  must  meet  the  same  standards  as 
macro  usage* 

Nonportable!  A  program  written  to  fit  a  specific  machine 
environment  and  Incapable-  of  running  lililftUi 
SfiUliAUiifiS  on  s L l  machine  envl ronaent** 

CSee  portable*] 

Portaole:  *  program  written  to  run  In  gny  machine  en¬ 
vironment  and  on  compiler.  Generally*  thl*  If  ac¬ 

complished  ny  restricting  the  urogram  to  the  use  of 
tho*e  hardware  feature*  which  are  common  to  nil  of  the 
machine  environment*  on  which  the  program  wilt  fun  and 
those  language  feature*  which  arc  1t*;>  l  evented  In  com¬ 
pilers  for  each  of  these  machine  envl ronmrnt  s •  This 
approve h  prohibits  the  programmer  from  mating  use  of 
*sch1ne-dependcn'<  or  compiler-dependent  features  for 
the  tale  of  efficiency. 

CSee  nonportable  I  COBOL. vbel  COBOL.  k|  MACU8.M 

C0B0L.ee*. 3 

Production  environment:  The  system  on  which  the  customer  or 
end  user  will  run  the  delivered  COBOL. k  program.  Per¬ 
formance  rwou  *  rC*<ent  5  are  OSSuncd. 

CSee  workb-neh] 

Progrea!  he  ^  l  -u  c  k  of  code  necessary  to  perform  some  tasl 
without  additional  1  ns  t  r  uc  1 1  oris  .  Usually  compiled  ar  ' 
loaded  separately. 

Program  Fealty!  The  set  of  C0;JQL*1  programs  defined  by  a 
Particular  COSOL.wbr  program  and  produced  by  macro  ex¬ 
pansion  using  MACLIB.I  where  1  represents  each  of  the 
target  machines  !r>  secuence. 

CSee  COBOL. wbc  program!  C08CL»k  prpgran] 

Progrem  Fragment:  An  Incomplete  section  of  code#  usually 
o nr  '  welch  or r form s  an  tndentlflbtd  task.  Cannot 
execute  without  additional  Instructions.  An  Incomplete 
orogr 

CSee  Program;  Module] 
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Program  Preparation  System!  Provided  to  assist  the  program¬ 
mer  In  developing  the  original  baseline  system*  as  well 
as  In  converting  or  t  rnnspor  t  Inn  that  system  to  various 
target  machines* 

PROJLIB*na»t !  A  library  file  containing  macro  definitions 
of  modules  developed  specifically  by  thr  project  team 
for  use  on  their  project* 

Prototype  Systea:  The  COBOL.wbc  program  th..t  defines  o 
family  a  1  COBOL. n  programs  during  testing*  before 
delivery.  The  first*  as  well  as  the  successive*  ap¬ 
proximation  towards  the  program  which  will  oc 
delivered. 

[See  breadboard] 

Ka lease :  defers  to  a  faellv  of  documents  «r.  1  ch  differ  from 
predecessor  or  successor  releases  by  virtue  of 
modification  for  efficiency*  expanded  capability*  or  to 
remove  errors.  This  concept  allows  several  grouos  to 
work  Independently  on  a  document  existing  In  several 
stages  or  releases.  for  example*  one  release  may  be  In 
production  and  another  In  development*  Thus*  one  qroup 
can  make  corrections  or  modifications  to  the  release  In 
production  with  no  effect  on  the  release  In  develop¬ 
ment. 

ISet  modlf Icat font  revision!  version] 

Reusable!  written  In  a  flexible  manner  so  that  the  code  may 
be  used  In  other  program  applications* 

CSee  module!  portable] 

Revision!  °efer»  to  *  document  which  differs  significantly 
from  predecessor  or  successor  revisions  !y  virtue  of 
modification  for  efficiency*  expanded  capability*  or  to 
remove  errors*  A  revision  consists  of  a  release  of  a 
document  one  the  version  of  the  release*  Thus* 

rny  U  |nn  2*3  Of  2  P.t  j  •  were  1/jn  \  q  4  r  0  \  f*  ft  S  (*  2  • 

CS*a  modification!  rclaasa!  version] 

Software  Tools  Subsystem  (SWT)!  An  Integretated  set  of 
automated  software  and  text  preparation  and  manipula¬ 
tion  routines. 

Csee  Section  5*2*2!  Appendices  A  through 

Source  Coda  Control  Systam  <$CCS>!  As  defined  in  hell  Lab;' 
Proorammer's  Workbench  CKoehkind  7b3»  fhl* 
maintains  and  provides  access  to  all  revisions  of  any 
document  * 

Standards  Enforcer!  A  routin'*  that  operates  as  a 

•preprocessor"  to  verity  that  the  standards  for 

COBOL. wbc  or  COBOL. k  are  followed  In  both  program  text 
and  documentation. 
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Test  Harness:  A  main  program  which  provide*  a  framework 
Into  which  a  modular  unit  can  be  placed  for  the  purpose 
of  testing*  A  driver  program*  expressed  a*  a  macro  and 
stored  In  TfSTLlB. 

[See  functional  testing] 

Text  Document*:  All  program  document  at  Ion  apart  from  com¬ 

ments  Internal  to  the  code*  Usually  Includes  program 
specification,  project  memos*  error  reports*  and  a 
ust-r»s  guide*  Maintained  on  line* 

Text  Oocumentat Ion  Preparation  System:  This  system  Is 

provided  to  assist  the  systems  «n;*tyst  In  the  prepara¬ 
tion  of  all  of  the  system  documentation  required  for 
t nr  support  cf  the  prototype  systems*  the  base  line 
system*  and  those  unique  varieties  of  the  system  that 
are  produced  to  rut'  on  the  various  target  machines* 

TCSTLIB:  a  library  file  containing  macro  definitions  of 

utility  functions  and  modules  to  aid  the  programmer  In 
testing  both  modules  and  programs  for  both  correctness 
and  pe r f or ranc e •  bhould  contain  only  let  Jed  code. 

Transportable:  4  prooram  written  to  run  In  iQ*  machine  en¬ 

vironment  and  on  &nx  compiler*  Generally*  this  Is  ac¬ 
complished  by  restricting  the  program  to  the  use  of 
those  hardware  features  which  are  common  to  all  of  the 
machine  environments  on  which  the  program  will  rur.  ana 
those  loniuage  features  which  are  Implemented  In  com¬ 
pilers  for  each  of  these  machine  environments*  This 
approach  prohlolts  the  programmer  from  maklno  use  of 
*  ■>  c  h  1  nr -dependen  t  or  compiler-dependent  features  for 
the  sake  of  efficiency*  Use  of  certain  machlno- 
aeoenlcnt  or  comp  1 1 c r-deoenden t  features  may  be  permit¬ 
ted*  If  any  necessary  modifications  can  ne  made 
auto* i t 1  cat l y. 

C  See  nonportable!  COBOL. wbc!  COBOL. k!  HACLIB.k! 
C0B0L.cc t* ] 

Transport#! Ion:  The  process  tnvolvcc  In  moving  a  program 

fro*  one  machine  to  another.  If  the  two  machines  ac¬ 
cent  the  sane  COBOL  dialect*  the  process  Is  mechanical! 
1C  the  two  dialects  Involved  differ*  extensive 
modification  may  be  reoulred* 

CSee  conversion] 

version:  “efers  to  a  particular  document  within  s  family  of 

documents  defined  by  a  release  of  a  document*  Version 
re'erg  to  a  document  resulting  fro*  specific 
mollifications  to  another  version  within  a  release* 

[See  modification!  release!  revision] 

Workbench:  a  comorehcns 1 vo  collection  of  capabilities  anu 

facilities  to  assist  the  COBOL  orodrammer  In  the 
development  and  preparation  of  complete  COBOL  systems 
suo ported  "y  full  documentation.  Other  capabilities  cf 


j 


l 

i 

i 
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the  Workbench  are  to  facilitate  the  development  of 
■prototype  or  breadboard*  COBOL  programs  from  a  collec¬ 
tion  of  reusable  COBOL  modules  and  to  facilitate  the 
preparation  of  COBOL  programs  that  may  be  easily  con¬ 
verted  to  a  number  of  different  target  machines  each 
having  Its  ovn  unique  dialect  of  the  COBOL  language. 
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APPENOIX  2 

AN  ANNOTATED  EXAMPLE  OP 
TRANSPORT  INC  A  WORKBENCH  COBOL  PROGRAM 


In  this  example*  the  "baseline*  program  Is  written  In 
COBOL. cemo*  the  demonstration  version  of  COROL.wbc.  Thr  two 
target  operatlnq  environments  are  the  Control  Data  Corpora¬ 
tion  CVOCft  70/7*  .and  the  PRIME  Comnuter  P4Q0  system*  This 
example  focuses  on  the  differences  In  the  form  and  content 
of  the  source  proqram*  however*  the  principal  technique  Il¬ 
lustrated*  the  use  of  macro  libraries*  can  also  be  applied 
to  some  of  the  other  Incompatibilities  In  the  operating  en- 
v 1 ronsent . 

IMPORTANT  NOTE:  In  the  examples  given  below*  lower 

case  letters  are  used  to  Indicate  colls  to 
reusable  modules  and  compiler-unique 
features*  Lower  case  Is  used  here  solely  as 
an  aid  to  the  reader*s  comprehension  and  con¬ 
veys  no  arioed  Information  to  the  macro 
processor.  All  characters  are  treated  by  the 
macro  processor  as  If  they  were  upper  case. 


2.1.  £££&£  um&iu 

The  macro  libraries  contain  the  definitions  of  the  nacres 
that  transform  the  program  from  COBOL.wnc  (demo)  to 
COBOL .target.  In  this  example*  there  are  two  macro 
libraries.  Vote  that  throughout  this  exanole  calls  or 
references  to  the  functions  In  these  libraries  are 
Identified  by  uslnq  lower-case  letters*  however*  this  Is  not 
required.  It  Is  done  In  the  example  to  hlqhllqht  the  calls. 
Also  note  that  "II"  and  "12"  refer  to  the  first  and  second 
arouatents  -liven  In  the  macro  call*  respectively. 

kikno.  ISLL  lilt  £&iS£ 


de  *  1 ne  < Id* 

irCfiTIF  I  CAT  ION  DIVISION. 

00OC°AM-SQ. 

1 1  . 

)  r'n  l 

def  tnc<coan.%cOMPuTATION4L>c!nl 

def  1nc(rcadcr**,FuS)dnl 
def 1ne(pr1nter«Dr^S)dnl 

def  1ne(  f  1  le_1d,  VALUF  OF  FlLC-IO  IS  MlMdnl 
def 1 ne ( c  vbe  r ♦ ) dnl 
def  1netp403*il>>Jnl 
def1netouote**SI,)cnl 
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fll&Xfi  klk£A£X  1 2L  ihl  il fttS 


define ( Id* 

IDENTIFICATION  DIVISION. 
PROGRAM-ID. 

$1. 

)  <1  n  t 

def 1ne(co*o3 ♦ COMPUTATIONAL >dn l 

deftne(reader»INPUT-F2)rinl 

de  ♦ Ine (printer. 0UTPUT-F2)dnl 

define  (f  He_1flt)dnl 

def Ine ( cyber . S l ) dn l 

def 1 ne  <  pAQO  » >  dnl 

define  (quote.  " *  1 " ) dnl 


2*2*  um&x 


A  programmer  usle.q  the  Workbench  wilt  need  to  have  access  to 
code  modules  that  are  common  to  all  those  working  on  a  olven 
project.  For  this  example,  we  assume  that  two  file  descrip¬ 
tions  are  to  be  shared,  and  that  one  COBOL  code  structure  (a 
multi-level  split  on  several  keys  In  a  sorted  file)  occurs 
often  enouoh  that  It  has  been  Included  In  the  project 
l Ibrar /. 


GtntcaL 

The  two  File  Description  modules  In  the  Project  Library  Il¬ 
lustrate  how  two  rather  drastic  differences  oetween  CYBER 
anc  PRIME  COBOL  are  treated.  These  differences  arc 


-  LABEL  RECORDS  statement  must  say 

—  STANDARD  in  PRIMC 
--  OMITTED  In  CYBER 

-  FILE  10  nust  oc 

--  VALUE  OF  FILE-ID  IS  _  In  PRIME 

--  omitted  In  CYBER 


Examining  the  macro  library  definitions  for  "cyber"  ard 
*o* 0 0 "  In  each  library  shows  how  the  °*00  library  causes 
entries  annotated  "cyber"  to  be  deleted  and  entries  an¬ 
notated  "o*Q0"  to  be  copied  Into  the  transported  program.. 
The  "cyber"  library  causes  just  the  reverse  action.  The  two 
definitions  for  "file-id"  handle  the  second  problem  oy 
generating  the  orooer  statement  for  the  PRIME  and  Ignoring 
It  completely  for  the  CYBER. 
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Paqe  1A6 


till  aimltUM  ttaflalt  lax  "&AkUdLXU£” 


FO  sales-file 

pAOO (LABEL  RECORDS  ARE  STANDARD) 
cyber (LABEL  RECORDS  ARE  OMITTED) 
f  He_ld(SALES) 

OATA  RECORD  IS  SAlES-RECGRO. 

31  SALES-RECORD. 


os 

salesman 

PICTURE 

X  <  5 )  . 

OS 

" ISTR ICT 

PICTURE 

XXX. 

^5 

s ales-oollars 

PICTURE 

9  ( S  >  V99 » 

Lilt  atiiilftlian  Lflduii  lax  "! 

Lit* 

F,  RCPORT-FILE 

pRCO  t LABEL  RECORDS  ARE  STANDARD) 
c ybe r ( L ARE L  RECORDS  aRC  OMITTED) 
f 1 te_ld(REPORT) 

OATA~RECORO  is  report-record. 

01  REPORT-RECORD. 


9  M 

CARRIAGE-CONTROL 

P1CTURT 

X. 

ns 

salesman-out 

PICTURE 

x  <  S  >  . 

0  5 

filler 

PICTURE 

xxx. 

as 

salesman-total-out 

PICTURE 

551 ,555, 11?. 9? 

or- 

p I L  LE  R 

PICTURE 

X  <  a )  . 

r«i 

"'ISTR  ICT-OUT 

PICTURE 

XXX  . 

CS 

FILLER 

PICTURE 

xxx. 

OS 

"ISTRICT-TOTAL-OUT 

PICTURE 

555,555,559.99 

OS 

FILLER 

PICTURE 

X  C  8  )  . 

G  5 

final-total-out 

PICTURE 

555,555,559.99 

BmtfaU  SAdMiu  lAinillltd  u  "aitiii* 


rtc 1 1 nc (nleve l  * 

MOVE  52  TO  PRE V l QUS-52  • 

PERFORM  U  UNTIL 

C1felse(S2«tt  52  IS  NOT  EQUAL  To  PR  E V I0US»5  2 

)  Ddnl 

C lfelse<53,,»  OR  53  IS  NOT  EQUAL  TO  PRCVI0US-5S 

)  lor. I 

t  Ifclscd*,,,  OR  5*  IS  NOT  EQUAL  TO  PR  E  V I OUS-5  A 

)  1'inl 

OR  NO-MORE-OATA. 


)  dn  l 


Georala  Institute  of  Technology 


COBOL  Workbench 


Appendix  2 


EXAMPLE 


Pact*  14? 


2.3.  Maa&amsH  m  gafl&aAH 


Now  that  the  pre 1 1*  1  na r  1e s  are  out  of  the  way*  the  oroaram- 
ner  can  create  a  program  In  "Workbench  Cobol»"  a  combination 
of  COBOL •  ccs  and  macro  call?.: 


BlItUQi  Elflfllll 


1  nc  l  ude  <  PRO  JL I P/NLC  VCD 

12<  TWOLCVCD 
ENVIRONMENT  DIVISION. 

INPUT-OUTPUT  SECTION. 

FILE-CONTROL. 

SELECT  SALfS-FILC  ASSIGN  TO  reader. 

SELECT  REPORT-FILE  ASSIGN  TO  printer. 

OATA  DIVISION. 

FILE  SECTION. 

1ncludc(PROJLIH/FO-SALE$-F  ILE> 
1nclude(PROJLIO/FD-REPORT-FILE) 

WORKING-STORAGE  SECTION. 

01  FUGS. 

05  NORC-DATA-FtAG  PICTURC  XXX  VALUE  ouotoCYES). 

88  KORE-OATA  VALUE  ouoteCYES). 

38  NO-MORC-CATA  VALUC  ouoteCNO  J. 

01  SAVC-ITEKS. 

05  PREVIOUS-SALESMAN  PICTURE  X<5>. 

05  PREVIOUS-DISTRICT  PICTURE  XXX. 

01  TOTALS  co*p3. 

05  SALESMAN-TOTAL  PICTURE  S9(0>V99  VALUE  ZERO • 

05  CISTRICT-TOTAL  PICTURE  S9(8)V99  VALUE  ZERO. 

05  FINAL-TOTAL  PICTURC  S9181V99  VALUE  ZERO. 

PROCEDURE  01 V i SI  ON. 

PRE PARE -SALE S-REPORT. 

OPrN  INPUT  SALCS-FILE. 

OUTPUT  REPORT-FILE. 

RC AO  SALES-FILE 

AT  END  MOVE  auotetNO  )  TO  KORE-OATA-FLAG. 

MOVE  ZERO  TO  FINAL-TOTAL. 

PERFORM  01  STRICT-TOTAL-PROCESS  INC 
UNTIL  NO-MORE-DATA, 

MOVE  SPACES  TO  REPORT-RECORD. 

MOVE  FINAL-TOTAL  TO  F INAL-TOT AL-OU'f » 

WRITE  REPORT-RECORD. 

CLOSE  SALES-FILEt 
REPORT-FILE. 

STOP  RUN. 
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£ 


nlcvel  <  SALES**  AN-TOTAL -PROCESSING.;)  I  STRICT) 

“OVC  SPACES  TO  RCPORT-RECORD. 

-OVT  PREVIOUS-DISTRICT  TO  D I  ST R I C T -OU T . 
«OVf  DISTRICT-TOTAL  TO  D I S TR I C T - T 0 T AL -OU T  . 
WRITE  REPORT-RECORD. 

ADD  DISTRICT-TOTAL  TO  FINAL-TOTAL. 

SALESMAN- TOTAL -PROCESSING. 

MOVE  ZERO  TO  SALESMAN-TOTAL. 

nlcvel (PROCESS- AND-RE AD. SALESMAN .DISTRICT) 


I 


MOVE  SPACES  TO  REPORT-RECORD. 

MOVE  PREVIOUS-SALESMAN  TO  salesman-out. 

MOVE  SALESMAN-TOTAL  TO  SALESMAN-TOTAL-OUT. 
URITE  REPORT-RECORD. 

ADO  SALESMAN-TOTAL  TO  DISTRICT-TOTAL. 
PRQCESS-A NO-READ. 

ADO  SALf S-OOLLARS  TO  SALESMAN-TOTAL. 

PEAO  SALES-FILE 

AT  END  wOVE  quote < NO )  TO  MORE-DAT A-Fl AG. 


4 


Ecsacii  fitli 

The  -*1  e  t  o  for  t  n  1  s  progna  It  preterit  In  the  file  "teles"! 


A  1  tOGl  0032 
M  10000300 
*1  1001000S 

‘3  ?  I  0  0  1  i  0  0  0 
bn  1103740 S 
f>9  U00606Z 

1R  2  0  0207(>9 
IT  P0CIP56C 
59  Z0Q19MS 
*■  9  30  0  1  2 1  A  0 

•i*  3  C  0  P  b  1  R  0 


■S' 


Hr*- 


ft 


m 


’■*>'  fv 


\m 
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|  2.4.  PROCESSING 

|  Using  the  workbench  utility  "convert."  the  Initial  program 

|  '  can  be  c gf}en<je<i  utilizing  the  Project  Library  and  then 

tr^n|^pr J;el  utilizing  the  '■aero  Libraries.  In  the  examples 
I  below  the  Intermediate*  expanded  versions  of  the  program  are 

not  listed.  Only  the  two  compiler-unique  forms  of  the 
program  are  listed  completely*  however*  the  results  of  the 
i  expansion  are  readily  apparent  In  the  file  definitions  and 

!  In  the  calls  to  "nlevel." 


} 


2.4.1  Prill  1M  JtltllflO 

Since  the  standards  enforcer  Is  not  available*  we  will  sim¬ 
ply  proceed  to  the  compilation*  linking*  and  execution  of 
the  P400  version  of  the  prooram. 


2. 4. 1.1  Pr1«*  400  Prograa 

RF V  l*  COBOL  SOURCE  F I LF:  EX.P400  06/09/7? 

(0001  > 

(0002) 

(0003) 

(000A)  IDENTIFICATION  DIVISION. 

(0005)  PROGRAM-ID. 

(0006)  TWOLFVEL. 

(  0  C  0  7  > 

(0C0P)  ENVIRONMENT  division-. 

(000*)  input-output  section. 

(0010)  F I LF-CON  TROL • 

(0011)  SELECT  SAUES-FILE  ASSIGN  TO  PFMS. 

(0012)  SELECT  REPORT-FILE  ASSIGN  TO  °FKS. 

(0013) 

(001«>  DATA  DIVISION. 

(0015)  FILE  SECTION. 

(  0  C  1  6 ) 

(0017)  F0  SALCS-FILE 

(0010)  LABEL  RECORDS  ARE  STANDARD 

C  2  0  1  *? ) 

(0020)  VALUE  OF  FILE-ID  IS  »SALES* 

(0021)  OATA  RECORO  IS  SALES-RECORD. 


(0022) 

01 

SALES-RECORC. 

(0023) 

05 

SALESMAN 

PICTURE 

X  ( 5 )  • 

(0024) 

05 

DISTRICT 

PICTURE 

XXX. 

(0025) 

(0026) 

(0027) 

05 

SALES-DOLLARS 

PICTURE 

9(5) V99. 

( G 0 2 8 )  FO  REPORT-FILE 

( 0 0 2 h )  LABEL  RECORDS  ARE  STANDARD 

(0030) 

(0031)  VALUE  OF  FILE-10  IS  ♦REPORT* 

(0032)  DATA  RECORD  IS  REPORT-RECORD. 

(0033)  01  REPORT-RECORD. 

(0034)  05  CARRIAGE-CONTROL  PICTURE  X. 
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(0035) 

05 

salesman-out 

PICTURE 

X(*=  »  . 

(0036) 

05 

filler 

PICTURE 

XXX. 

(0037) 

05 

salesman-total-out 

PICTURE 

*!*♦* JS9.99. 

(0038) 

05 

FILLER 

PICTURE 

X  t  3  >  . 

(0039) 

05 

OISTRICT-OUT 

PICTURE 

XXX. 

(0080) 

05 

FILLER 

PICTURE 

XXX. 

(0081 ) 

0  5 

OISTR1CT-TOTAL-OUT 

PICTURE 

0082) 

05 

FILLER 

PICTURE 

X  (  8 )  . 

(0083) 

0  5 

final-total-out 

PICTURE 

*$S«SSSttS9.99. 

(  C  0  8  8  ) 

(  0085) 

(0086) 

WORKING-STORAGE  SECTION. 

(0087) 

(  0  0  8  fl  ) 

01 

FLAGS. 

(  r  o  8  9  ) 

05 

MOSE-OATA-FLAS 

PICTURE 

XXX  VALUE  ‘YES*. 

(0050 

Pfi  MOHE-OATA 

value  'res*. 

(  C  05 1 ) 

88  NO-MORE-DATA 

VALUE  ♦NO  *. 

(f  052) 

(0053  ) 

01 

SAVf-IfEMS. 

(  0058  ) 

-1 5 

PREVIOUS-SALESMAN 

PICTURE 

X  (5)  . 

(0  055) 

05 

PREVIOUS-DISTRICT 

PICTURE 

XXX. 

(D056) 

(0057) 

01 

TOTALS  COMPUTATIONAL 

• 

(0058) 

05 

salesman-total 

PICTURE  S9 ( 8 ) V99  VALUE  ZERO. 

(0059) 

05 

DISTRICT-TOTAL 

PICTURE  S9(e>V59  VALUE  ZERO . 

(0060) 

05 

final-total 

PICTURE  S9(8)V99  VALUF  7ERO. 

(006  1  ) 

<cofe?>  procedure  division. 

( 0  C  6  3 )  oRTPARC-SALCS-REPOfiT. 

(006«)  OPEN  INPUT  SALES-PItE* 

(0065)  OUTPUT  REPORT-FILE. 

(0066)  READ  SALEWUE 

(C067)  AT  f  NO  MOVE  *  NO  •  TO  MORE-DATA-FLAO. 

(0  068)  MOVE  ZERO  TO  FINAL-TOTAL. 

(0069)  PERFORM  0 1 S TR I C T -TO T AL-PR OCES S I NG 

(0070)  UNTIL  NO-MORE-OATA. 

(0071)  MOVE  SPACES  TO  REPORT-RECORD. 

(0072)  MOVE  FINAL-TOTAL  TO  FINAL-TOTAL-OUT. 

(0073)  WRITE  RCPORT-RECORD. 

( 007* )  CLOSE  SALES-F1LE. 

(  0075)  REPOPT-fRE. 

(0076)  STOP  RUN. 

(0077) 

(0076)  DISTRICT-TOTAL -PROCESSING. 

(  C  0  7  -  )  'OVE  ZERO  TO  D  I  S  TR  I  c  T- TOT  AL  * 

(CORO) 

( r.  C  a  l  ) 

(00*2)  MOVE  DISTRICT  TO  PRE V I OUS -D I S TF I C T . 

(GG83)  PERFORM  SALESKAN-TOTAL-PROCCSSING  UNTIL 
( f.  0  8  A  )  DISTRICT  IS  NOT  EOUAL  TO  PREVIOUS-DISTRICT 

(008* )  OR  NO-MORE-OATA. 

(POPS) 

(0087) 

(COPR)  MOVE  SPACES  TO  REPOR T -RECORD. 

(0089)  ''OVE  PREVIOUS-DISTRICT  TO  OISTRICT-OUT. 

(0090)  MOVE  DISTRICT-TOTAL  TO  DISTRICT-TOTAL- OUT. 
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Pag/;  1  b  1 


<009l>  UMf  PCpORT-f?f. COK[)» 

<oo‘)?>  a  on  district-total  to  final-total. 

<0093) 

(0  094)  S ALES* AN-TOTAL-PROCESS  I NG. 

(0095)  MOVE:  2ES0  to  SALESMAN-TOTAL. 

(0096) 

<  0  09?) 

<0099)  MOVE  SALESMAN  TO  PREVIOUS-SALESMAN. 

<0099)  PERFORM  PR0CESS-AN0-RE AD  UNTIL 
<0100)  SALESMAN  IS  HOT  EQUAL  TO  PREVIOUS-SALESMAN 

<0101)  OR  DISTRICT  IS  NOT  EQUAL  TO  PRE V  I OUS-D I STR I C T 

<0102)  OR  NO-MORC-OATA. 

<0103) 

<0104) 

<010S>  MOVE  SPACES  TO  REPORT-RECORD. 

<0106)  M0VE  PREVIOUS-SALESMAN  TO  S ALESK AN-OU T . 

<0107)  MOVE  SALESMAN-TOTAL  TO  SALESMAN-TOTAL -OUT*. 

<0108)  WRITE  REPORT-RECORD. 

<0109)  ADD  SALESMAN-TOTAL  TO  D I S TR I C T- T OT AL . 

<0110) 

<0111)  PROCESS-ANO-READ. 

<0112)  400  SALCS-OOLLARS  TO  SALESMAN-TOTAL. 

<0113)  READ  SALES-FILE 

<0114)  AT  END  MOVE  «NO*  TO  MORE-DAT A-FLAG. 

58I/W/  "COMP*  IGNORED  FOR  OECIMAL  ITEM. 

59 1 /W/  “COMP*  IGNORED  for  DECIMAL  ITEM. 

61J/W/  "COMP"  IGNORED  TOR  DECIMAL  ITEM. 

0000  ERRORS  0003  WARNINGS.  P400/500  COBOL  REV  14.0  <TwOLfV> 


2.4.1. 2  Prime  400  Output 

The  output  of  the  P4G0  version  of  the  program  1st 


41 

1203.37 

52 

me. 00 

69 

1134.05 

1 

1448.02 

18 

1207.64 

32 

$  195.60 

2 

1393.29 

36 

119**15 

39 

1121.40 

50 

151.90 

3 

1367,35 

11*200.66 
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2.4.2  Xiiiian 


The  Cyber  vtri^on  ef  our  sample  program  uat  written  to  tape 
on  the  workbench  system)  and  then  transferred  to  the 
Cyber*  where  Its  compilation  and  esecutlon  yielded  the  fol- 
towlno  results. 


2. a. 2.1  CTBL'4  Program 

AO  0112  COBOL 


0000  1 
0000* 

0000’  IDENTIFICATION  DIVISION. 

CDOOA  PR06RAM-jQ. 

0000c  TWOUVCL. 

0000* 

00007  rNV  I  RONWENT  DIVISION. 

0000*  INPuT-OUTPUT  section. 
coooo  r ilc-covtrol. 

000  1  0  SELECT  SALES-Mi.E  ASSIGN  TO  INPUT-F2. 

^ 0 0 1 »  S'LECI  REPORT-FILE  assign  TO  OUTPuT-F 2 . 

000  12 

ooon  data  .'{vision. 

900  1*  MIC  SECTION. 

0001* 

OOJlf  FD  SALES-FiLE 
0001  7 

COOlo  L  'Bfl  c E C C R 0 S  APE  O-ITTCO 
3  0  0  l c 

00020  DATA  RECORD  IS  SALES-RECORD. 


00021 

01 

SALE  S-RECORD. 

0002? 

0* 

salesman 

PICTURE 

X  t  S  >  . 

0  0  0  2  5 

OS 

oistr i ; f 

PICTURE 

XXX. 

00Q2* 

05 

SALES-DOLLARS 

PICTURE 

«M5»V99 

0  00  25 
30020 

00027  rn  *Z*Oa'-'niZ 
0  0  0  2  * 

0002^  L A F r L  RECORDS  4«E  OMITTED 
000  ’0 


00051 

G  0  C  5  ? 

DATA  RECORD  is  report- 
01  » rpgR T-Pf CORD. 

RECORD. 

000  13 

0*' 

CARR  I  AGE-CONTROL 

PICTURE 

x. 

000  ,1R 

0’ 

SALESMAN-OUT 

PICTURE 

X  <  5  >  • 

OOO.’b 

0  ■ 

FILLER 

PICTURE 

XXX. 

00036 

0  J 

salesman-tot al-out 

PICTURE 

COO  5  ! 

05 

FILLER 

PICTURE 

X  tn»  . 

000''* 

Ob 

DISTRICT- OUT 

PICTURE 

XXX. 

''00  '0 

05 

FILLER 

PirTU°E 

xsx. 

SOOAG 

0-' 

CISTRICT-TOT AL-OUT 

PICTURE 

J  0  0  i 

0* 

FILLER 

FICTUPf 

05 

FtNAL-TOTAL-OUT 

p  JC  TU°E 

CQ0*  * 
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000«* 

000*5  «QR< ING-STOR AGE  SECTION, 
000*6 

000*7  PI  FLAGS, 


0  0  0*8 

05 

**O»C-0AT  A-FLAG 

PICTURE 

XXX 

VALUE  “ 

YES". 

ooo*p 

88  MORE -0 A  *  A 

VALUE  “ 

YES". 

0  0  0  5  0 

88  NO-MORC-DATA 

VALUE  " 

»*0  ". 

CQ051 

00052 

01 

SAVf-lTEMS. 

00053 

C  3 

PREVIOUS-SALESMAN 

PICTURE 

X  (  5  > . 

0005* 

05 

PRfVIOUS-OISTRICT 

PICTURE 

vxx. 

00055 

00056 

31 

TOTALS  COMPUTATIONAL. 

C00S7 

0  5 

s/  LESMAN-TOT AL 

PICTURE 

S9(8)V99 

VALUE 

ZERO. 

00058 

05 

DISTRICT-TOTAL 

PICTURE 

S9<6> V99 

VALUE 

ZERO. 

00059 

05 

FINAL-TOTAL 

PICTURE 

S9 1 8 ) V99 

VALUE 

ZERO. 

TWOLCVEAO  0112  COBOL 


00060 


TWOLEVEAO  0112  COBOL 


3006 1  PROCEDURE  DIVISION. 

00062  PRC0 ARE -SALE S-REPORT. 

00063  OPEN  INPUT  SAIPS-FIlC. 

0006*  OUTPUT  REPORT-FILE, 

0006*--  READ  SALCS-FILE 

00066  AT  CNO  MOVE  "NO  J  TO  MORE -0 A T A-F L *G. 

00067  MOVE  ZERO  TO  FINAL-TOTAL, 

000&e  PERFOR**  OISTR  ICT-T0TAL-PR0CESS1NC 

00Q69  UNTIL  NO-MOR E -0 A T A , 

00070  MOVE  SPACES  TO  REPORT-RECORD. 

00071  MOVE  FINAL-TOTAL  TO  F I NAl- TOT AL-OUT • 

0007?  WRITE  REPORT-RECORD. 

00073  CLOSE  SALES-FILC, 

00C  7*  'REPORT-PILE. 

00075  STOP  RUN. 

00076 

0  00  77  CIST* I CT -TOTAL-PROCESS  I  NO. 

00078  HOVE  ZERO  TO  DISTRICT-TOTAL. 

00079 

OOOPO 

QOOM  MOVE  DISTRICT  TO  PR  C  V  I OUS -0 1 S  TR  JCT  » 

000*?  PERFORM  SALESMAN-TOT AL-PROCCSSING  UNTIL 

00083  DISTRICT  IS  NOT  EQUAL  TO  PRf VIOUS-OJ STRICT 

OOCR*  OR  NO-MORE-OiTA, 

00085 

00086 

C0087  MOVE  SPACES  TO  REPOST-RECORD. 

00088  MOVE  PREVIOUS-DISTRICT  TO  DISTRICT-OUT. 

00QR9  MOVE  DISTRICT-TOTAL  TO  DISTRICT-TOTAL-OUT. 
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0G090  yfilTf  REPORT-RECORD. 

00091  ADO  DISTRICT-TOTAL  TO  FINAL-TOTAL. 

0009? 

;  00093  SALESMAN-TOT AL-PROCESS IMG. 

9009*  HOVE  ZERO  TO  S ALESHAN-TOT AL  . 

1  009  9'} 

0  0  0  9  £ 

00097  MOVE  SALESMAN  TO  PR C V  I OUS -S ALE SM AN  * 

0009*  PERFORM  PROCESS- ANO-RE *0  UNTIL 

000*9  salesman  is  not  equal  to  previous-salesman 

00  ICC  OK  }l STRICT  SS  NOT  EQUAL  TO  PR CV I OUS - p 1 S T R I C T 

SCI  91  OP  NO-MORE-OATA. 

0010? 

C010J 

0019a  move  SPACrS  TO  REPORT-RECORD. 

00105  MOVE  PREVIOUS-SALESMAN  TO  SM.ESKAN-OUT . 

0010*.  MOVE  SALTSMAN-TOT  Al  TO  SALESMAN-TOT  AL-OUT. 

0010?  V»!TC  REPORT-RECORD. 

mo*  ADO  SALESMAN-TOTAL  TO  DISTRICT-TOTAL. 

0010* 

3  C 1 1 C  "ROCESS-ANO-RCAD. 

30111  A >0  SALCS-DQLLARS  TO  SALESMAN-TOTAL. 

0011?  read  salcs-hle 

com  at  r  no  HOVE  "NO"  TO  MQR  E -D*  T  A -F  L  AG  . 

fwOLEVE  LENGTH  IS  0003a? 

.'-60200*  SC“  USED 


2.  A  . 

2.2  CYBER  Output 

A  1 

I  2  ( 3.2T 

1110.03 

69 

niA.fcK 

l  lAAfi.O? 

10 

T237.6* 

3? 

VlflS.60 

?  1393.29 

36 

51**.  15 

3* 

1 !.  2 1  •  A  0 

50 

r>i .ro 

3  l  if)  7. 35 


U*?0B.fct> 
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APPENDIX  3 
OOCUNCNT  CONTROL 


Thi>  Information  contained  In  thti  appendix  was  extracted 
from  a  research  paper  by  Timothy  G.  Saponas.  That  research 
paper  served  as  partial  fulfillment  of  the  first  year  Ph.'j. 
research  requirement  at  Georgia  Tech. 

Document  Control  Is  the  Workbench  facility  that  provides  for 
the  generation*  modification*  and  general  management  of  all 
revisions  of  tiny  document*  Aaonq  the  documents  which  art* 
serviced  by  Document  Control  are  COBOL  nodules* 
seclflcatlons*  manuals*  cat  a  loos*  and  reports.  wost  of  the 
discussion  concerning  Document  Control  will  refer  to  COBOL 
modules*  but  It  It  equally  applicable  to  any  other  document* 


3*i.  umiuim 

A  eocu*ent»  such  as  a  proqrem*  may  go  through  many 
revisions.  At  any  time  several  of  these  revisions  may  be  In 
ute.  For  example*  one  group  of  people  may  be  working  with 
program  A  in  production*  another  group  may  be  correcting 
known  buat  In  program  A*  and  still  another  orouo  may  be  e»- 
tending  the  capabilities  of  program  A*  This  obviously  could 
result  In  a  very  chaotic  situation  If  all  three  groups  are 
using  the  same  program.  Thus*  It  It  necetsary  for  Document 
Control  to  maintain  and  follow  a  document  through  alt  of  Its 
revisions.  Document  Control  should  Pe  able  to  create  any 
revision  at  any  point  In  time.  A  protection  mechanism 
should  be  provided  by  Document  Control  to  protect  against 
accidental  tampering.  Corrections  should  be  selectively 
propagated  to  those  revisions  which  need  It.  and  users  of 
revisions  later  than  those  changed  should  be  alerted  to  the 
changes.  Cach  revision  should  contain  a  release  number* 
version  number*  date  and  time  of  creation*  status  (produc- 
1 1  on  *  test*  development)*  and  history  Information  (who  made 
the  sod  1  f 1 c at  1  on*  what  it  consisted  of*  where  the  modifica¬ 
tion  occurred*  and  why  the  modification  was  made).  Finally* 
the  revision  control  program  shoulo  possess  useful  audit  In¬ 
formation  to  aid  management  In  following  the  progress  of  a 
project. 


3.2*  m  BUMma 

A  good  candidate  for  the  Document  Control  mechanism  Is 
described  In  CRochktnd  197b).  The  philosophy  of  this  method 
Is  that  the  text  common  to  more  than  one  revision  will  not 
be  duplicated.  The  fundamental  atom  used  to  record  Informa¬ 
tion  Is  called  a  delta.  Deltas  are  Identified  by  on  ordered 
oalr  (1«j)  where  1  refers  to  release  1  of  n  document  and  J 
refers  to  level  }  of  the  release,  we  will  denote  the  delta 
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obtain  the 
the  current 
de  t  tas  1*1 
In  all  cases 
/ll  changes 


corresoond tng  to  version  J  of  release  1  of  a  document  oy 
“D 1 ♦ )  •  *  A  d«  1 1  c  consists  of  list  a  of  changes  that  must  be 
applied  to  the  latest  previous  revision  to 
current  revision.  For  eiample,  to  obtain 
revision  for  the  situation  In  figure  a.3.2-1, 
through  l .  a  must  be  applied  In  succession, 
delta  i.l  wilt  represent  the  original  document, 
are  expressed  In  terms  of  the  primitives.  Insert  and  delete. 
Each  of  these  primitives  Is  performed  on  an  entire  line  of 
te«t«  For  example,  tc  represent  the  change  of  one  charac¬ 
ter,  one  would  delete  the  line  containing  the  character  anc 
Insert  a  new  line  containing  the  changed  character.  Ex¬ 
perience  has  shown  that  the  Information  which  Is  lost  by 
representing  all  changes  as  a  combination  of  Inserts  and 
deletes  Is  not  realty  essential  CKochklno  1975].  Thus, 
there  is  no  penalty  in  constructing  a  delta  from  a  series  of 
inserts  and  deletes. 


% 


FIGURE  a. 3. 2-1 
SCQUENCE  OF  FOUR  DELTAS 

indicating  four  revisions  of  a  module 


01. 1---01.2---01.3---01 • A 

01.2  represents  the  changes  that  aust  be  applied  to 


01.1  to  get  release  l*  version  2  of  e  document 


3.2.i  AisLlaa  Ulm  QjlUju 

Ve«  deltas  can  only  Be  applied  after  the  lost  dnlta  of  a 
release.  ’hus.  If  one  has  a  document  that  has  two  releases 
as  is  the  case  in  the  ex ample  depicted  In  figure  a, 3. 2. 1-1, 
and  It  is  <ie$1red  to  make  a  modification  to  release  1,  then 
the  new  delta  must  be  added  between  delta  1.,  and  delta  2.1. 
this  situation  could  occur  when  release  1  Is  bring  tested  by 
one  group  and  release  2  Is  being  developed  by  another  group. 
If  the  first  oroiip  finds  an  error  In  the  first  release,  del¬ 
ta  l.i>  oust  ne  added  to  correct  th?  error.  Delta  l.r-  will 
not  nc  use-i  to  obtain  any  version  of  a  release  after  release 
I  unless  an  optional  delta  as  explained  below  Is  applied; 
Instead,  a  warnlna  message  will  be  issued  Informin')  the  user 
t  h  it  a  modification  to  the  first  release  has  occurred. 
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FIGURE  a* 3. 2. 1-1 

THE  RESULTS  OF  AOOING  A  REVISION  TO  RELEASE  1 


01.1—01.2 D1.3— 01.  A - 02.1 - 02.2— 02.3— 02.  A 

I 

I 

I 

I 

add  01. S 
l 
I 
I 
I 

T 

Dl.l«-*0i*2---Dl*3-““01.4-,,-D1.5--“D2.i-“-02.2--,,D2»3---D2»A 


3*2*2  sattiii  fiiiui 

In  addition  to  these  deltas,  one  can  specify  two  Linos  of 
special  deltas.  The  first  Is  the  optional  delta.  These  are 
like  the  regular  deltas  esceot  that  associated  with  each  of 
these  deltas  Is  an  option  letter.  A  delta  of  this  type  will 
only  be  applied  If  the  option  letter  Is  presented  alonn  with 
the  reauest  for  the  specified  document.  This  Is  useful  In 
situations  In  which  one  wants  to  make  a  change  to  the  code 
to  provide  for  a  special  environ sent  experienced  by  a  subset 
of  users  but  wants  this  change  to  be  Invisible  to  the  rest 
of  the  users.  The  second  kind  of  special  delta  Is  used  to 
Indicate  whether  or  not  previous  deltas  are  to  be  Included 
or  excluded  fro*  the  revision  represented  Oy  the  special 
delta.  Tor  example.  If  It  Is  desired  to  re*ove  delta  1.3.  a 
special  delta  will  be  added  which  will  Indicate  that  delta 
1.3  Is  to  be  excluded  fro*  any  revision  beyond  this  point  In 
tlee.  This  eethod  prevents  the  risk  of  accidentally  remov¬ 
ing  code  that  may  be  later  found  desirable.  One  can  also 
use  this  special  delta  to  specify  the  Inclusion  of  previous 
deltas.  In  the  discussion  concerning  figure  o. 3. 2. 1-1.  It 
was  *ent1oned  that  delta  1.5  would  not  be  aoplled  to  obtain 
any  version  In  release  2.  If  the  change  represented  by  del¬ 
ta  1.5  is  desired  In  a  revision  of  release  2.  one  can  add  a 
special  delta,  delta  2.5.  that  reouests  the  Inclusion  of 
delta  1.5. 
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3*2*3  Xlut  SlfllAfli  al  fllUil 


|  All  the  oeltas  for  a  particular  document  are  placed  In  a 

data  structure  which  Is  designed  to  allow  the  parallel  ap- 
}  plication  of  all  deltas*  Each  document  <1.e*  set  of  del- 

I  tas)  Is  stored  In  a  separate  sequential  file  which  consists 

of  four  parts* 


?*.’ » i*  1  Header  Information 


I 

I 

M 

3fJ 


the  first  oart  Is  the  header*  which  contains  release  locks* 
a  list  of  programmers  authorljed  to  add  deltas*  an  Cnollsh 
description  of  the  module*  and  any  other  Information  that 
one  feels  Is  appropriate  for  the  header.  Next  In  the  file 
Is  the  release  taole.  This  contains  a  count  of  the  number 
of  deltas  In  each  release  (this  Is  useful  In  determining  the 
conf Igurat ion  of  storaqe  for  the  procetslnq  of  the  body  to 
be  described  cclow).  The  release  table  Is  followed  by  the 
delta  table*  which  contains  for  each  delta  the  release  num¬ 
ber*  level  number*  option  tetter  If  one  exists*  date  and 
time  It  was  added*  list  of  other  deltas  Included  or  excluded 
by  this  delta*  who  created  this  delta*  and  why  this  delta 
was  created.  The  last  oart  of  the  file  Is  the  body  In  which 
the  actual  deltas  are  placed* 


J.2.3.2  The  Main  Body 

The  body  contains  two  types  of  records*  text  records*  which 
contain  thr  source  code  Inserted  by  the  deltas*  ana  control 
records,  which  specify  the  effects  of  each  delta.  The 
control  record  uses  three  letters  (I*  3*  E >  to  Indicate  the 
action  to  be  taken  (Insert*  delete*  end  of  control)*  The 
release  and  version  nuahers  for  which  the  action  Is  to  be 
applied  are  also  specified  on  the  control  record.  An  exam¬ 
ple  of  -i  body  presented  In  CRochklnd  19753  Is  depicted  In 
figure  a*J*2»3*2— 1* 
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FIGURE  I.S.2.3.M 

EXAMPLE  BODY  PART  OF  THE  DELTA  FILE  OF  A  MODULE 


II.  1 
II. A 

test  of  1.4 
El. 4 

taut  of  1.1 

01.2 

•ort  text  of  1.1 
El. 2 
11.2 

text  of  1.2 
01.3 

■oft  text  of  1.2 
El. 2 

•Oft  ttxt  of  1.1 
El. 3 

■ort  ttxt  of  1.1 
El  *1 


Motlct  tht  bracketing  by  tie  E)  and  (Ot  E)  pairs. 
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3*2*«  Ecalttllao 


Document  Control  must  also  Include  a  method  of  protection 
against  accidental  tampering  and  chanqe.  As  mentioned  In 
the  dlscujjslon  above*  no  delta  can  be  reroved  physically 
from  tne  system!  Instead*  a  new  delta*  which  Indicates  that 
the  delta  of  Interest  Is  to  oe  Ignored  In  the  production  of 
a  revision*  must  be  constructed*  Thus*  one  can  oe  assured 
that  no  change  can  be  lost*  which  Implies  that  any  ac¬ 
cidental  damage  done  to  the  module  can  ultimately  be  correc¬ 
ted.  This  then  reduces  the  problem  to  one  of  preventing 
tanpcrlnq.  Obviously*  It  Is  Impossible  to  be  certain  that 
the  changes  being  made  are  valid*  Thus*  protection  must  be 
limited  to  screening  the  users  trying  to  make  changes  to 
modules*  ihls  can  be  implemented  by  associating  a  bit 
matrix  with  each  module  tRochklnd  19753*  One  dimension 
represents  the  names  of  the  programmers  allowed  to  modify 
the  module*  and  the  second  dimension  represents  the 
revisions  of  the  modules.  Thus*  each  programmer  con  mcolfy 
only  certain  modules  ana  certain  revisions  within  those 
modti l  es  • 


3*2*5  SUiaAaa  in 


an  i  flfl&di 


In  addition  to  protection  of  modules*  It  Is  necessary  to 
stamp  an  1  dent  1 f 1  cat  Ion  on  the  modules*  This  should  Include 
the  release  number*  version  number*  date  and  time  tnc  module 
was  last  modified*  the  names  of  the  programmers  responsible 
for  the  module*  and  the  status  of  the  module  (production* 
test*  development).  It  has  been  suggested  that  this  In¬ 
formation  ns  Incorporated  Into  the  module  In  such  a  way  that 
the  load  module  will  also  contain  this  Information  CFcochklnc 
1 9  7‘  3 .  In  f 030L  »  this  Information  could  be  stored  In  the 
working  storage  section.  In  fact  by  using  a  standard  nacre* 
this  tusk  could  be  easily  performed*  and  one  could  be 
Insured  of  a  uniform  system  of  Identification. 


3.3.  PE&Efi&BAMCL 


This  approach  to  the  problem  at  first  olance  appears  very 
costly  because  of  the  soace  reaulred*  but  this  anxiety  Is 
soon  curnc bed  by  the  following  statistics  taken  fro.*!  Csoch- 
klnd  19753*  The  statistics  were  based  on  the  largest  user 
group  on  on  19“  370.  The  group  Included  J00  programmers  and 
296*  modules*  This  resulted  in  I  *  »w55  deltas  which  occupied 
1.016.766  records*  There  was  an  average  of  five  deltas  per 
module.  Out  AOX  of  the  modules  had  only  one  delta.  Of  those 
with  more  than  one  delta*  the  average  was  7.5  deltas  per 
module.  There  were  126  modules  that  had  more  than  25  del¬ 
tas.  The  number  of  lines  of  code  resulting  from  all  the 
modules  t.ven  at  their  latest  revision  was  7RG.719.  This 
seent  that  there  was  37%  additional  soace  occupied  r>y  the 
deltas*  but  one  must  remember  that  this  was  obtained  by  coj- 
oarlm  the  soace  occuoled  by  only  one  revision  of  each 
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aodulc*  Thus*  Tor  37t  additional  space*  they  were  aclc  to 
possess  the  capability  of  accessing  any  revision  of  any 
sodule. 
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APPENDIX  4 

GEORGIA  TECH  SOFTWARE  TOOLS  SUBSYSTEM  COMMAND  INTERPRETER 


The  Software  Tools  Subsystem  Is  a  set  of  program  deve logmen t 
tools  based  on  the  book  £aiiMfi££  Iflali  by  nr  Ian  W*  Ker- 
n  1  a  h  a  n  and  P,  J  »  Plauger.  It  was  orlqlnully  oeveloped  for 
use  on  the  Prise  400  computer  In  197?  and  1978  In  the  form 
of  several  cooperating  user  programs*  The  present  Sub¬ 
system*  the  sixth  version*  1  r,  a  powerful  tool  that  aids  In 
the  effective  use  of  computing  resources* 

The  command  Interpreter*  „lso  referred  to  as  the  ih£li«  Is  a 
vital  oart  of  the  Subsystem*  It  Is  a  program  which  accepts 
conmands  typed  ay  the  user  on  his  terminal  and  converts  them 
Into  more  primitive  directions  to  the  computer  Itself*  The 
use  r  *  s  Instructions  are  expressed  In  a  special  medium  called 
the  £fii«flnfj  ifl£auaa£.  The  next  tew  sections  will  describe 
the  cornand  language  and  give  examples  of  how  It  is  used* 

Three  areas  will  be  covered  In  the  following  pages.  First* 
there  Is  a  tutorial  on  the  use  of  the  command  language* 
Second*  there  Is  a  summary  of  the  syntax  ana  semantics  of 
the  command  languaqe.  Lastly*  there  Is  a  selection  of  ap¬ 
plication  notes*  This  section  Is  a  good  source  of  useful 
technloucs  and  samples  of  advanced  usage. 


4.1*  TUTORIAL 


fitlllQfi  lll£Ud 

After  you  have  looped  In  to  the  computer*  you  must  start  up 
the  Subsystem.  To  do  this,  tyoe  the  command  ■swt": 

0**  swt 
1 

The  Subsystem  fires  uo  and  the  command  Interpreter  prompts 
you  for  Inout  by  tyolno  a  right  bracket* 


A*i*2  ixaia£iflJULul  fcamtiaULim 

The  rules  for  correcting  typos  under  the  Subsystem  may  vary 
from  system  to  system.  Usually*  the  Subsystem  exoects  a 
backspace  (control-h)  to  be  used  for  dcletlno  single  charac¬ 
ters  teat  are  In  error,  and  a  DEL  CRUBOUT  on  some  terminals) 
to  delete  entire  lines  that  are  In  error. 
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i  * 

!  In  the  next  fen  sections*  references  will  be  made  to  Input 

lines  that  are  terminated  with  a  •newline**'  You  should  use 
.  the  "newline*  key  on  a  terminal  only  If  the  terminal  lacks  a 

^  "return"  key*  They  do  not  necessarily  have  the  same  effect. 

i 

^  *•> i*3  Samoa! 

Input  to  the  command  Interpreter  consists  of  "commands • * 

Commands*  In  turn*  consist  of  a  "command  name*"  usually  mace 
up  of  letters  and  digits*  and  additional  pieces  of  1n- 
formation*  often  called  "parameters*  or  "arguments*"  (Note 
!  that  a  command  may  or  may  not  have  arouracnts*  depending-  on 

;  Its  function*)  The  command  name  and  any  arguments  .ire 

|  separated  from  each  other  oy  spaces* 

!  for  example: 

3  echo  Hello  world! 

Hello  world! 

3 

t 

IThe  command  name  Is  "echo"*  'Echo*  Is  not  a  very  Involved 
command*  It  simply  types  back  Its  parameters*  whatever  they 
may  be* 

I  Here  1 v  another  command*  one  that  Is  a  bit  more  useful: 


ec  guide  r.6800 

shell.doc  subsys  t1me_sheet 

zunde 


♦If*  Is  used  to  list  the  names  of  your  files* 


3  If 

adventure 

shell 

words 

1 


SaitlAi  to*  auallofl 

Some  characters  have  special  meaning  to  the  command 
!  Interpreter*  for  example*  try  typing  this  command: 

3  echo  Alas*  noor  Yorlck 
filas 

poor:  r:ot  found 

t  3 


This  strange  behavior  Is  caused  by  the  fact  that  the  comma 
Is  used  for  dark  mysterious  purposes  elsewhere  In  the  com¬ 
mand  language*  (The  comma  actually  represents  a  null  I/O 
connection  between  nodes  of  a  network*  See  the  section  on 
pipes  and  networks  for  more  Information*)  In  fact*  all  of 
the  following  characters  are  potential  t roublenakers ; 
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«  5  1  S  >  (  {  )  C  3  (  )  blank 

The  way  to  handle  this  problem  Is  to  use  •  You  may 

use  either  single  or  double  quotes»  but  be  sure  to  aatch 
each  with  another  of  the  same  kind.  Try  this  command  now: 

1  echo  "Alas,  poor  Yorlck?  1  knew  him  well." 

Alas*  poor  YorlckJ  I  knew  him  well. 

j 

You  can  use  Quotes  to  enclose  other  quotes: 

3  echo  ’Quoth  the  raven:  "Nevermore!"  * 

Quoth  the  raven:  "Nevermore!1* 

] 


A  final  word  on  quotations:  Note  that  anything  enclosed  In 
quotes  oecomes  a  single  arqument*  ror  example*  the  command 

1  echo  "Can  I  use  that  In  my  book?" 

has  only  one  arqument*  out 

]  echo  Can  I  use  that  In  «y  oook? 


has  seven. 


4.1.S  cam  oil  lUjli 

Suppose  you  have  a  task  which  must  oe  done  often  enough  that 
It  Is  Inconvenient  to  remember  the  necessary  commands  and 
type  thee.  In  every  time.  for  an  example*  let’s  say  that  you 
have  to  print  the  year-end  financial  reports  for  the  last 
five  years.  !*  the  "print"  command  Is  used  to  print  files* 
your  command  #  1  oh  t  look  like: 

J  print  year?.'  year  74  year  75  year76  year  /  7 

If  you  use  a  text  editor  to  make  a  file  named  "reports"  that 
contains  this  command*  you  can  then  print  your  reports  by 
typing 


:  reports 

No  socclal  command  Is  required  to  perform  the  operations  In 
this  "command  file?"  simply  typing  its  name  Is  sufficient. 

Any  number  of  commands  may  be  placed  In  a  command  file.  It 
Is  possible  to  set  up  groups  of  commands  to  be  reoeated  or 
executed  only  If  certain  conditions  occur.  Fee  the  Ap¬ 
plications  Notes  for  examples. 
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It  Is  one  o f  the  Important  features  of  the  command 
Interpreter  that  ccxxino  files  can  he  treated  exactly  like 
ordinary  commands.  As  shown  In  later  sections*  they  are  ac¬ 
tually  programs  written  In  the  command  lanquage?  many  Sub- 
System  commands  l*c*t  *1 os**  and  *rcl**  for  example)  are  Im¬ 
plemented  In  this  manner* 


4*1.6  saiga  Inii 


Ii££iilan 


Some  commands  can  accept  only  a  single  argument.  One  exam¬ 
ple  of  this  Is  the  *fos*  command*  "Fos"  stands  for  "format* 
overstrike*  and  spool."  It  Is  a  shorthand  command  for 
printing  "formatted*  documents  on  the  line  printer.  (A 
"formatted"  document  Is  one  prepared  with  the  help  of  a 
program  called  a  "text  formatter*"  which  Justifies  right 
margins*  Indents  paragraphs*  etc.  This  document  was 
prepared  by  the  Software  Tools  text  formatter*  called 
"1 » t • ">  If  you  have  several  documents  to  he  prepared*  It  Is 
very  Inconvenient  to  have  to  type  the  *fos*  command  for  each 
one.  A  special  technique  called  "Iteration"  allows  you  to 
"factor  out"  the  repeated  text.  For  example* 

, 3  fos  (file!  f 1le2  f 1le3> 

Is  equivalent  to 


]  fos  f 1  lei 
I  fos  file? 
3  fos  fllcJ 


The  oraumenta  Inside  the  parentheses  form  an  "Iteration 
group."  There  may  be  more  than  one  Iteration  group  In  a 
command*  but  they  must  all  contain  the  same  number  of  ar¬ 
guments.  This  Is  because  each  new  command  line  produced  by 
Iteration  must  have  one  argument  from  each  group.  As  on  Il¬ 
lustration  of  this*  note  that 


3  (echo  print  fos)  filed  2  3) 
Is  eoulvalent  tc 


3  echo  fllel 
3  print  f 1 le2 
3  fos  f1le3 


Iteration  Is  oerformec  by  a  simple  text  substitution?  If 
there  Is  no  sooce  between  an  argument  and  an  Iteration  group 
In  the  original  command*  then  there  Is  none  between  the  ar¬ 
gument  and  group  elements  In  the  new  commands.  Thus* 

filed  2  3) 

Is  equivalent  to 
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fltel 
f  Ue2 
file! 

Iteration  is  most  useful  when  combined  with  function  calls* 
which  will  be  discussed  later. 


l&iiuu  i£4  QtitlDititni  ai  oaIa 

Control  of  the  sources  and  destination*  of  data  Is  .«  very 
basic  function  of  the  consand  Interpreter,  yet  one  that 
deserves  soeclal  attention.  Every  program  and  conmano  In 
the  Subsystem  can  gather  data  from  certain  well-known  places 
and  deliver  It  to  other  well-known  places*  Oata  sources  arc 
known  as  lUfiki  caiil?  data  destinations  ore  calico 
iiitGilAIfl  awiftlll  astir- •  Pr  ograms  are  said  ti  "read  from 
standord  Input*  and  “writ?  on  standard  output**  The  key 
point  here  Is  that  p  rogra  ms  need  not  take  Into  account  how 
the  Inout  data  Is  rode  available  or  what  hapoens  to  the  out¬ 
put  data  when  they  are  finished  with  It?  the  command 
Interpreter  Is  In  complete  control  of  the  standard  ports. 

a  command  we  will  use  freauently  In  this  section  Is  ’copy*. 
•Copy*  aoes  cmclly  what  Its  name  Implies?  It  copies  data 
from  one  place  to  another.  In  fact*  It  copies  data  fro*  Its 
first  standard  input  port  to  Its  first  standard  output  port. 

The  first  point  to  resemper  Is  that  ££  fitiftStii*  IliGHALit 
GfilXi  LZltLHOLZ  iGl  it£2lCili*  Try  *copy*  now: 

cooy 

After  you  have  entered  this  command*  type  some  random  text 
followed  by  a  newline.  ’Copy*  will  type  the  same  te»t  back 
to  you.  When  you  tire  of  this  oa*c*  type  a  control-C?  this 
causes  on  end-of-fHe  signal  to  be  sent  to  ’copy**  which 
then  returns  to  the  command  Interpreter.  Typing  control-C 
to  cause  end-of-Mlc  Is  a  convention  observed  by  all  Suf  - 
systee  programs.)  '.Inc  you  did  net  say  otherwise*  standard 
Input  and  sfanpard  output  referred  to  the  terminal?  input 
data  was  taken  fro*  the  terminal  (as  you  typeo  It)  and  out- 
out  data  was  placed  on  the  terminal  torlnted  by  *cooy*>. 

Obviously*  fcooy*  would  not  be  of  much  use  If  this  was  all 
It  could  do.  Fortunately*  the  command  interpreter  can 
rhanoe  the  sources  and  destinations  of  data*  thus  makin.- 
♦copy*  less  trivial. 

S t anda rd  ports  *ay  oc  altered  so  as  to  refer  to  disk  files 
by  use  of  a  luCGSi.*  qr ea t e r- 1 h an  sicsn  (>>  Is  used  to 
represent  a  funnel.  '  onven  t  i  or.a  1 1  y  ♦  the  ">"  points  in  the 
direction  of  data  flow.  ?or  example*  i*  you  wished  to  copy 
the  contents  of  file  "cc"  to  file  "old_ee"»  you  could  type 
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1  ee>  copy  >old_ee 

12£  S£fiAi££riHAQ  ililD  "Uii  liXlXi  !l£  i*2£4iai£lX  DCii  lfi  iii 
instilled  iik£2i*£t  oa  iGiiixiaios  Siiioii  sulu  ilioxt*"  *i 

Hill  2Q£  !illQl  2Uli  i£fi££li£  lit  l>i  ll&fl  20X  ££2£AQ4  Q12£ 

ai  ai3ii*£Qii*  It ii  ££iUi£ilao  ii  attfiiianx  is  ioivtas  mu 
its:  £232104  lioaiiiai  £10  t£  iOi££fi££i£4  UGACtlUOlKllX* 

The  construct  *ce)*  Is  read  "fro*  re"?  ">old_re"  Is  rend 
•toward  old_ee."  Thus*  the  command  above  c*n  be  read  "tro* 
ee  copy  toward  old_ee»"  or*  "copy  fro*  ee  voward  olb_ee." 
The  orocess  of  changing  the  Hie  ass1on*ent  of  a  standard 
port  by  u»t'  of  a  funnel  is  calted  "I/O  r  ed  1  rec  t  1  on « •  or  sin- 
Dly  “redl rec t ton .  • 

it  Is  not  necessary  to  redirect  both  standard  Input  ana 
standard  outputt  either  any  be  redirected  Independently  c.1 
the  other*  Tor  e*a*ple* 

1  ee>  copy 

can  be  used  to  print  the  contents  of  file  "ee"  on  the 
terminal.  Oeseeber  that  standard  output*  since  1l  was  not 
specifically  redirected*  refers  to  the  terminal.)  Not 
surpr Is Ingl y »  the  last  variation  of  ‘copy** 

1  copy  >old_ee 

Is  also  useful.  This  :o*»an<j  causes  Inout  to  be  taken  fro* 
the  teralnal  (until  an  end-of-flle  Is  generated  by  typlnq  o 
control-C)  and  placed  on  the  file  "old^ee".  This  Is  a  quick 
way  of  creating  a  s«all  Hie  of  test  without  uslna  a  te*t 
editor. 

It  Is  Important  to  reallxe  that  5u2UCll£2  £££ii£lCi 

2£tlX£  UQiillSiX  xiiH  £M1£4  i£  ££4i£££lla0*  It  1*  a 4 
correct  to  redirect  the  output  of*  say*  •  1  f  • 

]  If  >f 1 le_l 1  it 

as  It  Is  to  redirect  the  output  of  ’copy** 

Although  the  discussion  has  been  limited  to  one  Input  port 
and  one  output  port  uo  to  this  point*  wore  of  each  type  arc 
available.  In  the  current  Implementation*  there  are  a  total 
of  sin  three  for  Input  and  three  for  output*  The  hlghest- 
nuwoered  output  port  Is  generally  used  for  error  messages* 
and  Is  often  called  "erroutT"  you  can  "capture"  error  Mes¬ 
sages  by  redirecting  this  output  port*  For  e*a*»ple«  If  any 
errors  are  detected  by  "If*  In  this  command 

3  If  i>errors 

then  the  resulting  error  wessages  will  be  placed  on  the  file 
"error*." 
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Final  word*  on  redirection:  there  are  two  spec  1  a l-purpose 
redirection  operator*  left*  They  are  both  represented  by 
the  character*  *>>"«  The  Mr*t  operator  Is  called  "append:" 

3  If  >> 1 1  * t 

cause*  a  list  of  file*  to  be  placed  ti  ike  £Qfl  fil  (appended 
to)  the  file  named  "list".  The  second  operator  1*  called 
"fro*  command  Input."  It  Is  represented  as  Just  >>  with  no 
file  name.  and  cause*  standard  Input  to  refer  to  the  current 
source  of  commands.  It  Is  useful  for  running  programs  like 
the  test  editor  from  "scripts*  of  Instruction*  placed  In  a 
command  file. 


4.1.6  ao4  tttUflxii 

The  tast  section  dlscuneo  1/0  redirection,  the  process  of 
making  standard  oorts  refer  to  d1*k  files,  rather  than  Just 
to  the  ter-inal.  This  section  will  take  that  Idea  one  step 
further.  rrequpntly.  the  output  of  one  proarem  Is  placed  on 
a  file,  only  to  be  picked  up  again  later  and  used  by  another 
program.  The  co»*and  Interpreter  slapllflet  this  process  by 
eliminating  the  Intermediate  file.  The  connection  between 
pro  grans  that  Is  so  for*cd  1*  called  a  fiiat*  ana  *  linear 
array  of  programs  c ommun 1 ea t Ing  through  pipes  Is  called  o 

decline* 

Suppose  that  you  maintain  a  large  directory,  containing 
drafts  of  various  annuals.  Each  draft  Is  In  a  file  with  a 
naar  of  the  forr  •*,ANs»*s.rr"»  where  "****"  Is  the  number  of 
the  manual  and  "r r •  Is  thr  revision  nu*bcr.  Tou  are  asked 
to  produce  a  list  of  the  numbers  of  all  manuals  at  the  first 
revision  stage.  The  following  command  will  do  the  Job: 

:  l *  -c  |  f Ino  .01 

"If  -c"  lists  the  n«oes  of  all  files  In  the  current  direc¬ 
tory.  Thr  "pipe  connection"  (vertical  bar)  couses  this 
listing  to  or  passed  to  the  ‘find*  command.  which  selects 
those  lines  contalnlno  the  string  ".01"  and  prints  then. 
Thus,  the  pipeline  above  will  print  all  filenames  watching 
the  conventional  for*  of  a  f 1 r s t - re v 1 s 1  on  manual  name. 

Thr  ability  to  build  special  purpose  commands  cheaply  ano 
Quickly  from  available  tools  using  pipes  Is  one  of  the  most 
valuable  features  of  the  command  Interpreter,  vlth  prac¬ 
tice.  surprisingly  difficult  problems  can  be  solved  with 
case.  for  further  e*anplcs  of  pipelines.  see  the  Ap¬ 
plications  votes. 
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Comb Ins t Tons  of  programs  connected  with  pipes  need  not  hr 
linear.  Since  multiple  standard  ports  are  available, 
programs  can  be  and  often  are  connected  In  non-linear 
networks.  (Some  networks  cannot  be  executed  If  the  programs 
In  the  network  ore  not  executed  concurrently.  The  command 
Interpreter  detects  such  networks,  and  prints  «  warning  mes¬ 
sage  If  they  cannot  be  performed.)  Further  Information  on 
networks  can  be  found  In  sections  6. 7.2.2.  6. 7. 2. 3.  and 
6. 7. 3.1. 


UA&auni  ruin 


It  Is  sometimes  necessary  to  chanoe  the  standard  port  en¬ 
vironment  of  many  commands  at  one  time,  for  rrosons  of  con¬ 
venience  or  efficiency.  The  "compound  node"  (a  set  of 
networks  surrounded  by  curly  braces)  can  be  used  In  thece 
sltuat Ions. 


As  an  example  of  the  first  case*  suppose  that  you  wish  to 
generate  a  list  of  manual  names  (see  the  last  example)  In 
either  the  first  or  the  second  stage  of  revision.  One  way 
to  do  this  Is  to  generate  the  list  for  the  Mrst  revision 
stage,  place  It  on  a  file  using  a  funnel.  then  generate  a 
list  for  the  second  revision  stage  and  place  It  on  the  end 
of  the  same  file  using  an  "append"  redirector.  A  compound 
node  might  simplify  the  procedure  thuslyt 

1  (  If  -c  j  find  .OH  If  -c  t  find  .02  )  Mist 


The  first  network  finds  alt  manuals  at  the  first  revision 
stage,  and  the  second  finds  all  those  at  the  second  stage. 
I  hr  networks  will  execute  le T t - 1 o-r 1 gh t .  with  the  output  of 
each  being  placed  on  the  file  "list."  thus  oeneratlno  the 
desired  listing,  with  Iteration,  the  command  can  be  collap¬ 
sed  even  farther; 


1  <  If  -c  |  find  .0(1  2)  )  >l1st 


This  combination  of  Iteration  and  compound  nodes  Is  often 
useful. 


Efficiency  becomes  n  c ons 1 dc r a 1 1  on  In  cases  -here  successive 
long  streams  of  data  are  to  be  copied  onto  »  MlcS  If  the 
"npoend"  redirector  Is  used  each  time*  the  file  must  be 
reopened  and  repositioned  several  times*  using  a  compound 
node,  the  output  file  need  be  opened  only  once! 


]  (  (fllel  f  1 1*2  f  1  le  3'  >  copy  )  >«ll.Ml«i 

This  complex  example  cooles  the  contents  of  files  "fllel." 
"f  1  le2.5*  and  "f  1le3"  Into  the  file  named  "all  files." 
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a.i.io  fyatiiao  £iUa 

Programs  In  the  Subsystem  receive  Information  through  their 
co«*and-l Ine  argument*  as  veil  as  their  standard  ports,  so 
It  Is  sometimes  useful  to  deliver  the  output  of  a  program  to 
the  command  Interpreter  for  further  processing,  rather  than 
to  a  olp«'»  The  "function  call*  mechanism  Is  available  for 
this  purpose,  for  eiample.  recall  the  situation  Illustrated 
In  the  section  on  pipes  and  networks*  suppose  It  Is  neces¬ 
sary  to  actually  print  the  manuals  whose  names  were  found. 
This  Is  how  the  task  could  be  done! 

)  print  C l f  -c  |  find  *013 

The  function  call  Is  composed  of  the  network  "If  -c  |  find 
.01"  and  the  souare  brackets  enclosing  It.  The  output  of 
the  network  within  the  brackets  Is  passed  t^  ‘print*  as  a 
set  of  arguments.  which  It  accesses  In  tie  usual  manner. 
Specifically,  all  the  lines  of  output  from  the  network  are 
combined  Into  onj  set  of  arguments,  with  spaces  provided 
where  multiple  llnet  have  been  collapsed  Into  one  line. 

•Print*  accrpts  multiple  arguments,  however,  suppose  It  was 
necessary  to  use  a  program  tike  *fos*»  that  accepts  only  one 
argument?  iteration  can  be  combined  with  a  function  call  TO 
do  the  S  o fc ’ 

3  f os  Klf  -c  |  find  .013) 

This  command  formats  and  prints  all  manuals  In  the  current 
directory  with  revision  nusoer*  "01". 

function  calls  are  frequently  used  In  command  files, 
particularly  for  accessing  arguments  passed  to  them.  since 
the  sequence  "If  -c  |  find  pattern"  occurs  very  frequently. 
It  is  a  good  candidate  for  replacement  with  a  command  file. 
It  Is  onty  necessary  to  oats  the  nattern  to  be  matched  Iron 
the  argument  list  of  the  command  file  to  the  ’find*  command 
with  a  function  call.  The  following  command  file.  called 
•files*,  will  Illustrate  the  process: 

If  -c  |  find  taro  13 

"ar  i  l"  retrieves  the  first  romnand  file  argument.  The 
funrtlon  call  then  passes  that  argueent  to  *f1nd»  through 
its  argument  list.  *riles*  ray  then  be  used  anywhere  the 
original  network  was  appropriate: 

3  files  .01 
1  or  lot  [files  .013 
i  fos  ([files  .013) 
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4.1.11  iuliklti 

It  has  Dcen  claimed  that  the  coanand  languaqe  Is  a 
programming  language  In  Its  own  right*  Cne  facet  of  this 
language  that  has  not  ocen  discussed  thus  far  Is  the  use  ot 
Its  variables*  The  command  Interpreter  allows  the  user  to 
create  variables*  with  scope*  and  assign  values  to  them  or 
refer  <ce  the  values  stored  In  the*. 

Certain  special  variables  are  used  by  the  commano 
Interpreter  In  Its  everyday  operation*  These  variables  have 
noses  that  begin  with  the  underline  <_>•  One  of  these  Is 
•..prompt"*  which  Is  the  prompt  string  the  command 
Interpreter  prints  when  requesting  a  command.  If  you  object 
to  "I*  as  a  prompt*  you  can  change  It  with  the  "set"  cot* 
•  and : 

)  set  _oro*ot  =  "OK*  * 

Ok*  set  _pro*pt  -  " X  " 

X  set  prompt  =  "  3  ° 

1 

You  way  create  and  use  variables  of  your  own.  To  create  a 
variable  In  the  current  scope  (level  of  command  file 
execution!*  use  the  "declare"  ccmano: 

1  declare  1  J  k  sum 

Values  arc  assigned  to  variables  with  the  ‘set*  command. 
The  command  Interoreter  checks  the  current  scope  and  all 
surrounding  scopes  for  the  variable  to  be  set*  If  found*  It 
Is  changed*  otherwise  It  1*  declared  In  the  current  scope 
and  assigned  the  soeclfled  value. 

Variables  behave  like  small  program*  that  print  their 
current  values.  Thus  the  value  of  a  variable  can  be  ob¬ 
tained  by  simply  t  yplnq  Its  name*  or  It  can  be  used  in  a 
command  line  by  enclosing  It  In  brackets  to  fora  a  function 
call.  The  following  command  file  (which  also  Illustrates 
the  use  of  *1f#*  ♦eval*»  and  *goto*>  will  count  from  1  to 
the  number  given  as  Its  first  argument: 

declare  1 
set  1  =  1 
:  loop 

If  teval  1  ">"  taru  133 
goto  exit 
f  1 
1 

set  1  =  [ eval  1*13 
goto  loop 
:ex  1 1 

Note  the  use  of  the  "eval"  function*  which  treats  Its  ar¬ 
guments  as  an  arithmetic  expression  and  returns  the  expres¬ 
sion’s  value.  This  Is  required  to  Insure  that  the  string  "1 
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♦  1"  1*  Interpreted  as  an  expression  rather  than  as  a 
character  string*  Also  note  that  *M»  terminates  the  »1f» 
command* 

In  the  future*  typed  variables  and  better  control  structures 
■111  he  added  to  the  command  Interpreter. 


4.1.12  Conclusion 

This  concludes  the  tutorial  section*  for  the  command 
Interpreter.  T<e*p1te  the  fact  that  a  pood  deal  of  material 
has  been  presented.  much  detail  has  been  omitted.  The  next 
ne*t  few  sections  Include  a  complete  summary  of  the 
capabilities  of  the  command  Interpreter  and  some  examples 
which  may  prove  heloful. 


<•2*  amax  ai  mua  m  xmusA 

fhls  section  I*  the  definitive  document  for  thr  syntax  and 
ccr responnlna  semantics  of  the  Software  Tools  Subsystem  Com¬ 
mand  Interpreter.  It  Is  composed  of  several  sub- tec t 1 ons * 
each  cover  1n*j  some  major  area  of  command  syntax.  with 
discussions  of  the  semantic  conseguer.ces  of  employing 
particular  constructs.  It  Is  not  Intended  a*  a  tutorial, 
nor  Is  It  Intended  to  supply  multitudinous  examples!  ether 
sections  In  this  document  are  provided  to  fill  those  needs. 


££111041 


<co«x«nd>  : :=  C  <nct>  <  (  <net>  )  3  <newl1ne> 


The  £122104  1*  the  basic  unit  of  communlcat 1  on  between  the 
command  Interpreter  and  the  user.  It  consists  of  any  number 
of  networks  (described  below!  separated  by  semicolons  and 
terminated  bv  a  newline.  The  networks  arc  executed  one  at  a 
I  tier.  1 ef t - 1 o-r  Igh t $  should  an  error  occur  at  any  point  In 

S  the  parse  or  execution  of  a  network,  the  remainder  of  the 

|  <co-*>ond>  is  Ignored.  The  null  command  Is  legal,  and  causes 

|  no  ac  t 1  on. 

|  The  command  Interpreter  reads  commands  for  Interpretation 

;  fro*  the  £12*104  11U£££*  This  Is  Initially  the  user»s 

j  terminal,  although  execution  of  a  command  iiil  may  change 

the  isslonnent.  Whenever  the  command  source  It  the 
j  terminal,  and  the  command  Interpreter  Is  ready  for  Input.  It 

prompts  th<>  user  with  the  string  contained  In  the  shell 
,  variable  • _oronpt*.  Since  this  variable  may  be  altered  by 

|  the  user*  the  prompt  string  Is  selectable  on  a  oer-user 

.  basis* 
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A  <npt>  generate*  «  block  of  ( p^ns 1 b l y  concurrent)  processes 
that  are  bound  to  one  another  by  channels  for  the  flow  of 
data*  Typically*  each  <node>  corresponos  to  a  single 
process*  KNode>s  are  described  In  *ore  aetall  below*) 
There  Is  no  predefined  "execution  order*  of  the  processes 
conoosing  a  <net>J  the  co*«and  Interpreter  will  select  any 
order  It  sees  fit  In  order  to  satisfy  the  required 
Inout/outout  relations.  Jn  particular*  the  user  Is 
specifically  enjoined  no^  to  at*u*e  a  lef t-to-rlght  serial 
execution*  since  *o*e  <net>s  cannot  oe  executed  In  this  man¬ 
ner. 

Jnput/outout  relations  between  <node>s  are  specified  with 
the  <node  separator)  construct*  The  following  discussion 
■ay  be  useful  In  visualizing  the  data  flows  In  a  <net>*  ano 
clarlflng  the  function  of  the  components  of  the  Cnode 
separator). 

The  entire  <net>  way  be  represented  at  a  directed  graph  with 
one  vertex  for  each  <node>  (typically*  euulvalent  to  each 
process)  In  the  net.  lach  vertex  nay  hove  up  to  n  arcs 
terminating  at  It  ( reoresent Ina  Ingot  flgfra  street) *  and  j£ 
arcs  originating  fro"  It  (represent  Ing  gyjLKMl  ftfl  Ifr  ? t  rea»s  >  » 
An  arc  between  two  vertices  Indicates  a  flow  of  data  froi-. 
one  <node>  to  another*  and  Is  physically  Implemented  by  a 

fach  of  the  q  possible  Inout  points  on  a  <node>  1$  assigned 
an  Identifier  consisting  of  a  unlaue  Integer  In  the  range  1 
to  Q.  These  Identifiers  are  referred  to  as  the  e£Lt  DiiSfelHi 
for  the  standard  Input  ports  of  the  given  <nodc>.  Similar¬ 
ly*  each  of  the  a  possible  output  points  on  a  <node>  Is  as¬ 
signed  a  unique  Integer  In  the  range  1  to  a*  referred  to  as 
the  port  nu*bers  for  the  JLtfiQilUl  outouj  ports  of  the  g^ven 
<node>* 

lastly*  the  <node>s  thc*>selaes  are  numbered*  starting  at  l 
and  Increasing  by  1  fro*  the  left  end  of  the  <net>  to  the 
r  Ir.ht  • 
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Clearly.  In  order  to  specify  any  possible  Input/output  con¬ 
nection  between  any  two  <node>*.  It  1*  sufficient  to 
spec  1 f y : 

1*  The  number  of  the  "source"  <node>. 

2«  The  number  of  the  "destination"  <node>. 

3.  The  port  number  of  the  standard  output  port 
on  the  sour i  Cnode)  that  Is  to  be  the  source 
of  the  data. 

4.  The  oort  nusbcr  of  the  standard  Input  port  on 
the  destination  Cnode)  that  Is  to  receive  the 
data. 

The  syntax  for  <node  separated  Includes  the  specification* 
for  the  last  three  of  these  ttems.  The  source  <node>  Is  un¬ 
derstood  to  be  the  node  that  Immediately  proceeds  the  <node 
separator)  under  cc  Ideratlon.  The  special  Cnode 
separator)  "."  1*  used  ,o  separate  <node)s  that  do  not 
partlcloate  In  oata  sharing?  It  specifies  a  null  connection. 

HlJil*  I'll  <Q2Sl£  lS&AIfti££>  ft  IftAQl  111  tftilfclift&iM 

iCH  afiillail  ftflQQftlilftQ  fitftiftfttl}  i*fl  Hi  A  given 

<nr  t ) . 

The  full  flexibility  of  the  <node  separator)  Is  rarely 
needed  or  desirable.  In  order  to  wake  effective  use  of  the 
capabilities  provided*  suitable  defaults  have  been  designed 
Into  the  synta*.  The  semantics  associated  with  the  defaults 
are  as  follows? 

1.  If  the  output  port  number  (the  one  to  the 
left  of  the  vertical  bar)  Is  omitted.  fthg 
2.CJL1  UDAiJLiaOfid  HUlHHl  HHLl  <1q  Incr^ilgg 
aiiSftlltfti  ILltV  ii  Implied.  This  default 
action  takes  place  pp^y  after  the  entire 
<net>  has  been  examined,  and  all  non- 
defaulted  output  ports  for  the  given  node 
have  been  assigned.  Thu*.  If  the  first  Cnode 
separator)  after  a  <node>  has  a  defaulted 
cutout  port  number,  port  1  will  be  assigned 
If  and  only  If  no  other  Cnode  separator)  at¬ 
tached  to  that  <node)  references  output  port 
1*  It  Is  an  error  for  two  <ncde  separators) 
to  reference  the  sane  output  port.  (This 
particular  behavior  may  be  changed  In  the 
future  to  allow  "forklnq"  output  streams, 
which  would  be  copied  to  more  than  one 
dest Inat Ion. ) 

2.  1 4  the  destination  Cnode)  number  Is  omitted, 

then  the  next  node  In  the  <net)  (scanning 
iron  left  to  rlqht)  Is  Impl  led., /^Frequently  a 
null  <no oc>  Is  generated  at  end  of  a 
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<net>  because  of  the  necessity  for  resolving 
such  references. 

3.  If  the  destination  Cnode>*s  Input  port  number 
Is  omitted*  then  the  next  unasslgncd  Inou? 
port  (In  Increasing  numerical  order)  Is  Im¬ 
plied.  As  with  the  defaulted  output  port* 
this  action  takes  place  only  after  the  entire 
<net>  has  been  examined.  The  comments  under 
(1)  above  also  apply  to  defaulted  Input 
oorts. 

In  addition  to  the  defaults*  speclfylno  Inout/output  connec¬ 
tions  between  widely  separated  <node>s  Is  aided  by  alter¬ 
native  means  of  giving  <node>  numbers.  The  last  <node>  In  a 
<net>  may  be  referred  to  by  the  <node  number?  »*  and  any 
<node>  may  be  referred  to  by  an  alphanumeric  <label>. 
<  <S’ode>  labelling  Is  discussed  In  the  section  on  <node> 
syntax*  below.)  If  the  first  <node>  of  a  <net  >  Is  labelled* 
the  <net>  may  serve  as  a  target  for  the  »qoto*  command;  see 
the  App llcatlons  Notes  for  examples. 

As  will  be  seen  In  the  next  section*  further  syntax  Is 
necessary  to  completely  specify  the  Input/output  environment 
of  a  <node>I  the  reader  should  remember  that  <node 
seoarator>s  control  only  those  flows  of  data  between 

fiiaituu* 

A  few  examples  of  the  syntax  presented  above  may  help  to 
clarify  some  of  the  semantics.  Since  the  syntax  of  Cnode> 
has  not  yet  been  discussed*  <node>s  will  be  represented  by 
the  string  "node"  followed  by  a  digit*  for  unlouenets  and  as 
a  key  to  <node  number>s. 

A  simple  linear  <net>  of  three  <node>s  without  defaults: 

nodel  1  1 2 « 1  node2  113.1  node3 

(Data  flows  from  output  port  1  of  nodel  to  Input  port  1  of 
node  2  and  output  port  1  of  node?  to  Input  port  1  of  node3.) 

The  sa«e  <net>«  with  defaults! 

nodel  j  node?  I  node3 

(Note  that  the  spaces  around  the  vertical  bars  are 
S*.0d4la£X»  so  that  the  lexical  analysis  routines  of  the  com¬ 
mand  Interpreter  can  parse  the  elements  of  the  command  unae~ 
b 1 ouous l f • ) 

A  simple  cycle! 

nodel  1 1 • 2 

(Oata  flows  from  output  port  I  of  nodel  to  Input  port  ?  of 
nodel.  Other  data  flows  are  unspecified  at  this  level.) 
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A  branching  <net)  with  resolution  of  default*: 
nodel  |*  node2  |.l  nodes 

(Data  flow*  from  output  port  1  of  nodel  to  Input  port  2  (!) 
of  node3  and  output  port  1  of  node?  to  Input  port  1  of 
nodes . ) 


A. 2. 3  Node* 


Cnorie)  ::=  :<label)  t  <s1mple  node)  |  <co*p'  *1  node)  3  I 
<  <s1«ple  node>  |  <compound  node> 

<*1*ple  node>  ;:=  (  <1/o  redirector)  )  <command  name) 

(  <1/o  redirector)  |  <argument>  3 

<coapound  nooe>  l‘.~  (  <1/o  red1rector>  ) 

<net>  (  <.net  separator)  <net>  )  *)• 

(  <1/o  red1rector>  ) 

<1/o  red1rector>  ::=  <f1le  name)  •)*  C  <oort>  3  | 

t  <port>  3  *)♦  <f1le  nane)  | 

C  <port>  3  •>>*  <f1le  name)  j 

•>)•  t  <port>  3 

<not  separator)  t;=  1 

< coesand  name)  ::=  <f1le  name) 

< label >  ::=  <1dent1Mer> 


The  <node>  Is  the  basic  executable  element  of  the  command 
language*  !t  consists  o»  a  label  (strlnq  of  letter** 
digits*  and  underscores*  beginning  with  a  letter)*  or  an  op¬ 
tional  label  followed  by  one  of  two  additional  structures* 

The  first  ootlon  Is  the  cslnple  node)*  It  specifies  the 
none  of  a  command  to  be  performed*  any  arquments  that  com¬ 
mand  *ay  require*  and  any  <1/o  reo1rcctor>s  that  will  affect 
the  data  '•nvlronocnt  of  the  command  In  addition  to  <p1pe 
connection)*  In  any  <nets)  containing  the  <s1mple  node)* 
(<l/o  redirectors  will  be  discussed  below*)  The  execution 
of  a  simple  node  normally  Involves  the  creation  of  a  single 
process*  which  performs  some  function*  then  returns  to  the 

operating  system* 

The  second  option  Is  the  <compound  node)*  It  specifies  a 
<r.et>  wnlch  Is  to  be  executed  according  to  the  usual  rules 
of  <net>  evaluation  (sec  the  previous  section)*  and  any  <1/o 
re.-j1rector)s  that  should  affect  the  environment  of  the 
<n«t)»  The  <compound  node)  Is  provided  for  two  reasons* 
One*  It  Is  occasionally  useful  tc  alter  default  port  asslo- 
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nments  for  an  entire  <net>  with  <1/o  red  1 r ec t or > s *  rather 
than  supplying  <1/o  red1rector>s  for  each  <node>.  Two.  use 
of  compound  nodes  containing  more  than  one  <not>  gives  the 
user  some  control  over  the  order  of  execution  of  his  proces¬ 
ses.  These  abilities  are  discussed  In  more  detail  below. 

Since  It  Is  the  bo re  basic  construct,  consider  the  <s inp  t  e 
node>.  It  consists  of  a  <co«»and  n<»«e>  with  <drgueent>s. 
Intermixed  with  <1/o  red  1  ree  t  o  r  >  s.  The  <command  na*.?>  must 
be  a  filename.  usualty  specifying  the  name  of  an  object  code 
file  to  be  loaded.  The  command  Interpreter  locates  the  com¬ 
mand  to  be  performed  by  use  of  a  user-specified  search  ry^£. 
The  search  rule  resides  In  the  shell  variable 
"_search_rule"»  snd  consists  of  a  series  of  con«a-separateo 
elements.  Each  element  Is  either  a  template  In  which  amper¬ 
sands  ( A )  are  replaced  by  the  <command  name?  or  a  flag 
Instructing  the  command  Interpreter  to  search  one  of  Its 
Internal  tables.  The  flag  •<*1nt"  Indicates  that  the  command 
Interpreter's  repertoire  of  Internal  commands  Is  to  be  chec¬ 
ked.  (An  Internal  command  is  implemented  as  a  subroutine  of 
the  commend  Interpreter,  typically  for  speed  or  because  of  a 
need  to  access  some  private  data  base.)  The  flag  *‘var* 
causes  a  search  of  the  user*s  shell  v rlablcs  (see  below  for 
further  discussion  of  variables  and  functions).  The  follow¬ 
ing  search  rule  will  cause  the  command  interpreter  to  search 
for  a  command  aaono  the  Internal  commands,  shell  variables* 
and  the  directory  /bln.  in  that  order: 

"*1nt»“var./b1n/4" 

The  purpose  of  the  search  rute  Is  to  allow  optimisation  of 
command  location  for  speed,  and  te  admit  the  possibility  of 
restricting  some  users  from  accessing  "privileged"  commands. 
(For  example,  the  search  rule 

"“var./project/llbrary/l" 

would  restrict  a  user  to  accessing  his  variables  and  those 
coanands  In  the  directory  /pro J ec t /l Ibr ar y •  He  could  not 
atte“  this  restriction,  since  he  does  not  have  access  to  the 
(Internal)  *set*  command;  the  "*1nt"  flag  Is  missing  from 
his  search  rule.) 

<Ar gument >s  to  be  passed  to  the  program  being  readied  for 
execution  are  fathered  by  the  command  Interpreter  and  placed 
In  an  area  of  memory  accessed  by  the  library  routine 
•getaro*.  They  may  be  arbitrary  strings*  separated  from  the 
command  name  and  from  each  other  by  blanks.  Quoting  may  be 
necessary  If  an  <argu*ent>  could  be  Interpreted  as  some 
other  element  of  the  command  syntax.  Either  single  or 
double  quotes  may  be  used.  The  appearance  of  two  strtnas 
adjacent  to  one  another  without  blanks  Implies 
concatenat Ion.  Thus. 

"Quoted  "string 
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Is  equivalent  to 

"quoted  string" 

or  to 

quoted*  string* 

Single  quotes  may  appear  within  strlnas  delimited  by  double 
quotes*  and  vice  versa;  this  Is  the  only  way  to  Include 
quotes  within  a  string.  Example: 

"•quoted  string*" 

•"Alas*  poor  Yorlck!"* 

Arguments  are  generally  unprocessed  by  the  command 
Interpreter*  and  so  eay  contain  any  Information  useful  to 
the  program  being  Invoked. 

!n  the  previous  section*  It  was  shown  that  streams  of  data 
from  "standard  ports"  could  be  piped  from  prograe  to  program 
through  the  use  of  the  <p1pe  connect1on>  syntax.  It  Is  also 
possible  to  redirect  these  data  streams  to  files*  or  to  use 
files  as  sources  of  data.  The  construct  that  makes  this 
possible  Is  the  *11/o  red1rector>.  The  <1/o  red1rector>  Is 
composed  of  filenames*  port  nuabers  (as  described  In  the 
last  section)*  and  one  or  more  occurrences  of  the  "funnel" 
<>) . 

The  two  simplest  foras  take  Input  froa  a  file  to  a  standard 
port  or  output  froa  a  standard  port  to  a  file.  In  the  case 
of  delivering  output  to  a  file*  the  file  1$  autoaat 1  cal ly 
created  If  It  did  not  exist*  and  overwritten  If  It  did.  In 
the  case  of  taking  Input  froa  a  file*  the  file  Is 
unmodified.  Example: 

document  a  1 1 on> 1 

causes  the  data  on  the  file  "docuaentat  lor."  to  be  passed  to 
standard  In* ut  port  1  of  the  node! 

1 >resul  t  s 

causes  data  written  to  standard  output  port  1  of  the  node  to 
be  placed  cn  the  file  "results". 

If  no  <1/o  red1reetor>  1*  present  for  a  given  port*  then 
thet  port  nutomat leal  ly  refers  to  the  user’s  terminal. 

If  oort  numbers  are  omitted*  an  assignment  of  defaults  Is 
made.  The  assignment  rule  Is  Identical  to  that  given  above 
for  <p1ee  connect 1ons>t  the  first  available  port  after  the 
entire  <net>  hms  been  scanned  Is  used.  <1/0  red1rector>s 
are  evaluated  tef t-to-r Ight *  so  leftmost  defaulted  redirec¬ 
tors  are  assigned  to  lower-numbered  ports  than  those  to 
their  right.  ror  example* 
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da  t  a>  requests>  trans  2>summary  3>errors  |  spool 
Is  the  same  as 

data>l  reouests>2  trans  2>summary  3>crrors  1 f  2 • 1  spool 

where  all  defaults  have  been  elaborated.  ‘Trans*  night  he 
some  sort  of  transaction  processor*  accepting  data  Input  and 
update  requests*  and  producing  a  report  there  printed  off¬ 
line  by  belnq  piped  to  a  spooler  proqram)*  a  summary  of 
t ransact Ions «  and  an  error  lifting. 

In  addition  to  the  <1/o  redtrector>e  mentioned  above*  there 
are  two  lesser-used  redirectors  that  are  useful.  The  first 
I  output  to  a  file*  rather  than  overwriting  the  file* 

The  syntax  Is  Identical  to  the  other  output  reolrector*  with 
the  exception  that  two  funnels  •>>•  are  used*  rather  than 
one.  For  example* 

6»stuf  f 

causes  the  data  written  to  output  port  6  to  be  appended  to 

t he  file  "stuff".  (Note  the  lack  of  spaces  around  the 

redirector;  a  redirector  and  Its  parameters  are  never 
separated  from  one  another*  but  are  g Iwf y»  separated  from 
surrounding  arguments  or  other  text.  This  restriction  Is 
necessary  to  Insure  unambiguous  Interpretat Ion  of  the 
redirector.)  The  second  redirector  causes  Input  to  be  taken 
from  the  current  command  source  file.  It  Is  most  useful  In 
conjunction  with  command  files.  The  syntax  Is  similar  to 

the  Input  redirector  mentioned  above*  but  two  funnels  are 

used  and  no  filename  may  be  specified.  As  an  example*  the 
following  segment  of  a  command  file  uses  the  text  editor  to 
change  all  occurrences  of  "March"  to  "April"  In  a  given 
file: 

>>  ed  file 

g/March/s//Apr1l/ 

w 

0 

When  the  editor  Is  Invoked*  It  will  take  Input  directly  from 
the  command  file*  and  thus  It  will  read  the  three  commands 
placed  there  for  It. 

The  "command  source"  and  "append"  redirectors  are  subject  to 
the  same  resolution  of  defaults  as  the  other  redirectors  and 
<o1pe  connect 1on>s.  Thus*  In  the  example  Immediately  above* 

>>  ed  file 

Is  equivalent  to 

»1  ed  file 
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Now  that  the  syntax  of  <node>  has  been  covered*  just  two 
further  considerations  remain.  First*  the  nature  of  an 
executable  program  Must  be  defined.  Second*  the  proDlcm  of 
execution  order  must  be  clarified. 

In  the  vast  majority  of  cases*  a  <node>  is  executed  by 
bringing  an  object  program  Into  memory  and  starting  it. 
However*  the  <co«mand  naae>  way  also  specify  an  internal 
command*  a  shell  variable*  or  a  command  file.  Internal  con- 
■and*  are  executed  within  the  connand  Interpreter  by  the  in¬ 
vocation  of  a  subroutine.  When  a  shell  variable  is  used  as 
a  connand*  the  net  effect  is  to  print  the  value  of  the 
variable  on  the  first  output  port*  followed  by  a  newline. 
If  the  filenane  soeeified  is  a  text  file  rather  than  an  ofce 
Ject  file*  the  coanand  Interpreter  "guesses"  that  the  named 
file  is  a  file  of  commands  to  be  Interpreted  one  at  a  tine-. 
In  any  case*  command  Invocation  is  uniform*  and  any  <1/o 
redirector>  or  <pipe  connection>  given  will  be  honored. 
Thus*  it  is  allowable  to  redirect  the  output  of  a  connand 
file*  Just  as  if  It  were  an  object  program*  or  copy  a  shell 
variable  to  the  line  printer  by  connecting  it  to  the  spooler 
through  a  pipe. 

As  Mentioned  In  the  section  on  <net>s*  the  execution  order 
of  nodes  in  a  <net>  is  undefined.  That  is*  they  nay  be 
executed  serially  In  any  order*  concurrent ly«  or  even  simul¬ 
taneously.  The  exact  method  is  left  to  the  implementor  of 
the  command  Interpreter.  In  any  case*  the  flows  of  data 
described  by  <pipe  connection^  and  <1/o  redirectors  are 
guaranteed  to  he  present.  There  are  times  when  It  would  be 
preferable  to  know  the  order  in  which  a  <net>  will  be 
evaluated!  to  help  with  this  situation*  Ccompound  nodes  nay 
be  used  to  effect  ser laliration  of  control  flow  within  a 
network.  c.VetS  separated  by  semicolons  or  newlines  are 
guaranteed  to  oe  executed  serially*  lef t-to-r ight*  otherwise 
the  command  Interpreter  would  exhibit  unpredictable  behavior 
as  the  user  typed  in  his  commands.  Suppose  it  is  necessary 
to  operate  four  programs!  three  may  proceed  concurrently  to 
make  full  use  of  the  multiprogramming  capability  of  the  corn- 
outer  system*  but  the  fourth  must  not  be  executed  until  the 
second  of  the  three  has  terminated.  For  simplicity*  we  will 
assume  there  are  no  input /out put  connection*  between  the 
programs.  The  following  command  line  meets  the  reauirements 
stated  above: 

prograal*  (program?!  program*)*  programs 

(Recall  that  the  comma  represents  a  null  i/o  connection.) 
Suppose  that  we  have  a  slightly  different  problem!  the 
fourth  program  must  run  after  the  other  three  had  run 
to  completion.  This*  too*  can  be  expressed  concisely: 

nrograml*  program2*  programs!  program* 

Thus*  the  user  has  fairly  complete  control  over  the  execu- 
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?1on  order  of  his  <net>s.  (The  use  of  commas  and  semicolons 
in  the  command  language  parallels  their  use  for  collateral 
and  serial  elaboration  In  Algol  88. ) 

This  completes  the  discussion  of  the  core  of  the  command 
language.  The  remainder  of  the  features  present  In  the  com¬ 
mand  Interpreter  are  provided  by  a  built-in  preprocessor » 
which  handles  function  calls*  Iteration*  and  comments.  The 
next  few  sections  deal  with  the  preprocessor**  capabilities. 


4.2.4  Comments 

Any  good  command  lenguage  should  provide  some  means  for  the 
user  to  comment  his  code*  particularly  In  command  files  that 
may  be  used  by  others.  The  command  Interpreter  has  a  simple 
comment  convention:  Any  text  between  an  unquoted  sharp  sign 
CS)  and  the  next  newline  is  Iqnored.  A  comment  may  appear 
at  the  beginning  of  a  line*  like  this: 

•  command  file  to  prep.rocets*  compile*  and  link  edit 

Or  after  a  command*  like  this: 

fHe.r>  rf  «  Ratfor**  output  goes  to  the  terminal 

Or  even  after  a  label*  for  Identification  of  a  loop: 

Hoop  a  beginning  of  dally  cycle 


At  far  as  Implications  In  other  areas  of  command  syntax*  the 
comment  Is  functionally  equivalent  to  a  newline. 


miihiii 

<var1able>  ::  =  <1dent1f1er> 

<set  conm#nd>  ::*  set  C  <varimble>  3  *  l  <ergu«ent>  3 
<declare  co»mand>  ! ! =  declare  C  <var1able  C  s  <argument>  3  ) 
<forget  comaand>  ::=  forget  <vmr1abte>  (  <var1able>  ) 


The  command  Interpreter  supports  named  string  storage  areas 
for  miscellaneous  user  applications.  These  are  called 
vgr H jblej.  Variable*  are  Identified  by  a  name*  consisting 
of  tetters  of  either  ease*  digits*  and  underscores*  not 
beginning  with  a  digit.  Variables  have  two  attributes: 
value  and  scope.  The  value  of  a  variable  may  be  altered 
with  the  *set*  command*  discussed  below.  The  scope  of  a 
variable  Is  fixed  at  the  time  of  Its  creation!  simply* 
variables  declared  during  the  time  when  the  command 
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Interpreter  It  taking  Input  fro*  a  command  file  are  active 
as  long  as  that  file  It  being  uted  at  the  commend  source. 
Variables  with  global  scope  (those  created  when  the  command 
Interoreter  Is  readlnq  commands  froe  the  terelnal)  are  saved 
os  part  of  the  user’s  profile,  and  to  are  available  from 
terminal  session  to  terminal  session.  Other  variables 
disappear  when  the  execution  of  the  command  file  In  which 
they  were  declared  terminates. 

Variables  may  be  created  with  the  ’declare*  command. 
•Oeclare’  creates  variables  with  the  qlven  names  at  the 
current  lexical  level  (within  the  scope  of  the  current,  com¬ 
mand  file).  The  newly-created  variables  are  assigned  a  null 
value,  unless  an  Initialization  string  Is  provided. 

variables  may  be  destroyed  prematurely  with  the  »forge,t* 
command.  The  named  variables  are  removed  from  the  command 
Interpreter’s  symbol  table  and  storage  assigned  to  them  Is 
released  to  the  system.  Note  that  variables  created  by 
operations  within  a  command  file  are  automatically  released 
when  that  command  file  ceases  to  execute.  Also  note  that 
the  only  way  to  destroy  variables  at  the  global  lexical 
level  Is  to  use  the  ’forget*  command. 

The  value  of  a  variable  may  be  changed  with  the  ’set’  com¬ 
mand.  The  first  argument  to  ’set*  Is  the  name  of  the 
variable  to  be  chanqed.  If  absent,  the  value  that  would 
have  been  assigned  Is  printed  on  ’set’s  first  standard  out¬ 
put.  The  last  argument  to  ’set*  Is  the  value  to  be  assigned 
to  the  variable.  It  Is  uninterpreted,  that  Is.  treated  as 
an  arbitrary  string  of  text.  If  missing.  ’set*  reads  one 
line  from  Its  first  standard  Input*  and  asslqns  the  result- 
inn  string.  If  the  variable  named  In  the  first  argument  has 
not  been  declared  at  any  lexical  level,  ’set*  declares  It  at 
the  current  lexical  level. 

Variables  are  accessed  by  name*  at  with  any  command.  (Note 
that  the  user’s  search  rule  must  contain  the  flag  "*var" 
before  variables  will  be  evaluated.)  The  command 
Interoreter  orlnts  the  value  of  the  variable  on  the  first 
standard  output.  This  behavior  makes  variables  useful  in 
function  calls  (discussed  below).  In  addition,  the  user  may 
ootaln  the  value  of  a  variable  for  checking  simply  by  typing 
Its  name  as  a  command. 


n IIlHftH 


<1terat1on>  =  ♦(♦  <ele*ent>  l  <element>  )  •)• 


Iteration  Is  used  to  generate  multiple  command  lines  each 
differing  by  one  or  more  substrings.  Several  Iteration 
elements  (collectively,  an  "Iteration  group")  are  placed  In 
parentheses;  the  command  Interpreter  will  then  generate  one 
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command  line  for  each  element*  with  successive  elements 
replacing  the  Instance  of  Iteration.  Iteration  takes  plate 
over  the  scope  of  one  <net>*  It  will  not  extend  over  a  <net 
separators  (If  Iteration  Is  applied  to  a  <compound  node>* 
It  will*  of  course*  apply  to  the  entire  <node>t  not  just  to 
the  first  <net>  within  that  <node>.) 

Multiple  Iterations  may  be  present  on  one  command*  each 
Iteration  group  must  have  the  same  number  of  elements*  since 
the  command  Interpreter  will  pick  one  element  from  each 
group  for  each  qenerated  command  line.  (Cross-products  over 
Iteration  groups  are  not  Implemented. ) 

An  example  of  Iteration: 

3  fos  parttl  2  3) 

Is  equivalent  to 

3  fos  partll  fos  part2t  fos  parts 
and 

3  cp  (Intro  body  summary)  part(l  2  3) 

Is  equivalent  to 

3  cp  Intro  partll  cp  body  part2t  cp  summary  parts 


EyptilM  till* 


<f*inct1on  call>  Its  *C  *  <net>  {  <net  separator>  <net>  3  *3* 


Occasionally  It  Is  useful  to  be  able  to  pass  the  output  of  a 
program  along  as  arguments  to  another  program*  rather  than 
to  an  Input  port.  The  luCLtiifiQ  &&L1  make*  this  possible. 
The  output  appearlnq  on  each  of  the  first  standard  output 
ports  of  the  <net>s  within  the  function  call  Is  copied  Into 
the  command  line  In  place  of  the  function  call  Itself.  Line 
separators  (newlines)  present  In  the  <ne,t>*s  output  are 
replaced  by  blanks.  No  quoting  of  <net>  output  Is  per¬ 
formed*  thus  blank-separated  tokens  will  be  passed  as 
separate  arguments#  (If  quoting  Is  desired*  the  filter 
•quote*  can  be  used  or  the  shell  variable  "^quote^opt*  may 
be  set  to  the  strlnq  "TES"  to  cause  automatic  quotation.) 

A  <net>  may  of  course  be  any  network*  all  the  syntax 
described  In  this  document  Is  applicable.  In  particular* 
the  name  of  a  variable  may  appear  with  the  brackets!  thus* 
the  value  of  a  variable  may  be  substituted  Into  the  command 
line. 
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This  concludes  the  description  of  command  syntax  and 
semantics*  The  next  section  contains  actual  working  exam¬ 
ples  of  the  full  command  syntax*  along  with  suggested  ap- 
pl Icat Ions* 


tmiuim  salts 

The  next  few  sections  consist  mostly  of  examples  of  current 
usage  of  the  command  Interoreter.  Extensive  knowledge  of 
tone  Subsystem  programs  may  be  necessary  for  complete  under¬ 
standing  of  these  examples*  but  basic  principles  should  be 
clear  without  this  knowledge* 


* 


* 

1 


4.3.1  suit  Euo&Uaai 

In  this  section*  some  basic  applications  of  the  command 
languaqc  will  be  discussed.  These  applications  are  Intended 
to  give  the  user  a  "feel"  for  the  flow  of  the  language* 
without  being  explicitly  pedagogical. 

One  commonly  occurring  task  Is  the  location  of  lines  In  a 
file  that  match  a  certain  oattern.  The  ’find*  command  per¬ 
forms  this  function! 

]  f1le>  find  pattern  >l1nes_f ound 

Since  the  lines  to  be  checked  against  the  pattern  are 
frequently  a  list  of  file  names*  the  following  sequence  oc¬ 
curs  often! 

3  If  -c  directory  j  find  pattern 

Consequently*  a  command  file  named  ’files*  Is  available  to 
abbreviate  the  sequence: 

3  cat  files 

If  -c  Cargs  23  J  find  Caro  13 

(•Cat*  Is  used  here  only  to  print  the  contents  of  the  com¬ 
mand  file.)  The  Internal  command  *arg*  Is  used  to  fetch  the 
first  argument  on  the  command  line  that  Invoked  *f1les*. 
Similarly*  the  Internal  command  »args*  fetches  the  second 
through  the  last  aroumonts  on  the  command  line.  The  command 
file  gives  the  external  appearance  of  a  program  ’filet*  such 
that 


3  files  pattern 
Is  equivalent  to 

3  If  -c  j  find  pattern 
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and 

3  file*  pattern  directory 
Is  equivalent  to 

3  If  -c  directory  |  find  pattern 

Once  a  list  of  file  names  Is  obtained*  It  1-  frequently 
orocessed  further*  as  In  this  command  to  print  Ratfor  source 
files  on  the  line  printer: 

3  or  Cflles  •  r  i  1  sort3 

•File**  produces  a  list  of  file  names  with  the  ".r"  suffix* 
which  Is  then  sorted  by  ’sort**  *Pr*  then  prints  all  the 
named  files  on  the  line  printer. 

One  problem  arises  when  the  pattern  to  be  matched  contains 
command  language  metacharacters.  When  the  pattern  Is  sub- 
stltuteo  Into  the  network  within  •files**  and  the  commend 
Interpreter  parses  the  command*  trouble  of  tome  kind  Is  sure 
to  arise.  There  are  two  solutions:  One*  the  filter  *quote* 
can  be  used  to  supply  a  layer  of  quotes  around  the  pattern: 

If  -c  Cargs  23  |  find  Carg  1  |  quote3 

Two*  the  shell  variable  •„quotc-,opt  • »  which  controls 
automatic  function  Quotation  by  the-  command  Interpreter*  can 
be  set  to  the  string  "YES*: 

declare  _quote„oot  =  YES 
If  -c  Cargs  23  |  find  Carp  13 

This  latter  solution  works  only  because  *args*  prints  each 
argument  on  a  separate  line*  the  command  Interpreter  always 
generates  separate  arouments  from  separate  lines  of  function 
ojtput.  In  practice*  the  first  solution  Is  favored*  since 
the  non-lntult Ive  quoting  Is  made  more  evident. 

One  common  non-linear  command  structure  Is  the  so-called  "Y" 
structure*  where  two  streams  of  data  Join  together  to  form  e 
third  fatter  some  processing).  This  situation  occurs 
because  of  the  presence  of  dyadic  operations  fespeclatly 
comparisons)  In  the  tools  available  under  the  Subsystem.  As 
an  example*  the  following  command  compares  the  file  names  In 
two  directories  and  lists  those  names  that  are  present  In 
both: 


3  If  -e  dlrl  J  sort  |l  If  -e  d1r2  f  sort  |  common  -3 
Visualize  the  command  In  this  way: 
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If  -c  dlrl  |  sort 
\ 

\ _ 


If  -c  d1r2  |  sort,. 
/ 

_/ 


\  / 
common  -3 


The  two  • l f •  and  ♦sort*  pairs  produce  tlsts  of  file  names 
that  are  comoared  by  ’common**  which  produces  a  list  of 
those  names  common  to  both  Input  lists. 


Command  files  tend  to  be  used  not  only  for  often  perforaed 
tasks  but  also  to  aake  life  easier  when  typing  long*  complex 
commands.  Oulte  often  these  long  command  lines  aake  use  of 
line  continuation  --  a  newline  preceeded  Immediately  by  an 
underscore  Is  Ignored.  The  following  command  file  Is  used 
to,  create  a  key word-ln-context  Index  from  the  heading  lines 
o.lp the  Subsystem  Reference  Manual*  Although  It  Is  not  -used 
frequently.  It  does  a  great  deal  of  work  and  Is  Illustrative 
of  many  of  the  features  of  the  command  Interpreter. 


#  aakr_cmd.k  build  perauted  Index  of  commands 

files  /doc_?  -f  coamands^f lies  _ 

|  chanqe  X  "find  X.hd  " 

I  . 

|  change  *X.hd  •  ([“  >>  C  ■  ]•{[-■ 3* ) ?*•  *818  82* 
I  kwlc  -d  /extra/soel l Inq/dl scird  _ 

J  sort  -d  |  unrot  -w  [width]  >cmd.k 


First  a  few  words  on  how  Subsystem  documentation  Is  stored: 
The  documentation  for  Subsystem  commands  resides  In  a  sub* 
directory  named  "co*mends„f 1 les".  The  documentation  for 
each  command  Is  In  a  separate  file  with  the  name 
doc_<co(8mand>.  The  heading  line  In  each  file  can  be 
Identified  by  the  characters  ".hd"  at  the  beginning  of  the 
l  Inr. 


The  entire  command  file  consists  of  a  single  network*  The 
•files*  command  produces  a  list  of  the  full  path  names  (the 
-f  option  Is  passed  on  to  *lf*>  of  the  files  In  the  sub¬ 
directory  *com»ands_f lies"  that  have  path  names  containing 
the  characters  "/doc_"  followed  by  at  least  one  additional 
character.  The  next  ’change*  command  generates  a  ’find* 
command  for  each  documentation  file  to  find  the  heading 
line.  These  commend  lines  are  passed  back  to  the  shell 
<*sh’>  for  execution.  The  outputs  of  all  of  these  ’find* 
commands*  namely  the  heading  lines  from  all  the  documenta¬ 
tion  files*  Is  passed  back  on  the  first  standard,  output  of 
♦  sh • .  The  second  ’change*  command  uses  tagged patterns  to 
Isolate  the  command  name  and  Its  short  description  from  the 
header  line  and  to  construct  a  suitable  entry  for  the  kwlc 
Index  generator.  Finally*  ’kwlc**  ’sort**  and  *unrot* 
produce  the  Index  on  the  file  "cmd.k". 
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To  this  point*  only  serially-executed  commands  have  been 
discussed*  however  sophisticated  or  parameterized*  Control 
structures  are  necessary  for  more  generally  useful  ap¬ 
plications*  The  following  command  file*  ♦ssr**  shows  a 
useful  technique  for  parameter-setting  commands*  Like  many 
APL  system  commands*  •ssr*  without  arguments  prints  the 
value  It  controls  (In  this  case*  the  user*s  command  search 
rule)*  wh'le  *ssr*  with  an  argument  sets  the  search  rule  to 
the  aroument  given*  then  prints  the  value  for  verification* 
•Ssr*  looks  like  this: 

*  ssr  ---  set  user*s  search  rule  and  print  It 

If  Cnargs] 

set  search  rule  =  targ  1  |  quote] 

fl 

_search_rule 

The  •If*  command  conditionally  executes  other  commands.  It 
reaulres  one  argument*  which  It  Interpreted  as  **true"  If  It 
Is  oresent*  not  null*  and  non-zero.  If  the  argument  Is 

true*  all  the  commands  from  the  »1f*  to  the  next  unmatched 
•else*  or  »f1»  command  are  executed*  If  the  argument  Is 

false*  all  the  commands  from  the  next  unmatched  ’else*  com¬ 
mand  (If  one  Is  present)  to  the  next  unmatched  *M*  cormano 
arc  executed*  In  *ssr*  above*  the  aroument  to  • 1 f •  Is  a 
function  call  Invoking  •nargs**  a  command  that  returns  the 

number  of  arquments  passed  to  the  command  file  that  Is 

currently  active.  If  •nargs*  Is  zero*  then  no  arguments 
were  soeclfled*  and  *ssr*  does  not  set  the  user’s  search 
rule.  If  *n»rgs*  Is  nonzero*  then  *str*  fetches  the  first 
argument*  quotes  It  to  prevent  the  command  Interpreter  from 
evaluating  special  characters*  and  asslqns  It  to  the  user’s 
search  rule  variable  *_,seareh_rule  *  • 

♦If*  Is  useful  for  simple  conditional  execution*  but  It  Is 
often  necessary  to  select  one  among  several  alternative  ac¬ 
tions  Instead  of  Just  one  from  two*  The  ’case*  command  Is 
available  to  perform  this  function*  The  premier  example  of 
•case*  Is  the  command  file  *e**  which  Is  used  to  Invoke 
either  the  screen  editor  or  the  line  editor  depending  on 
which  terminal  Is  being  used  (as  well  as  remembering  the 
name  of  the  file  last  edited): 
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*  e  Invoke  the  editor  best  suited  to  a  terminal 


If  Cnargs3 

jet  f  =  Carg  1  |  quote] 
f  1 

ease  Cline] 
when  10 

se  -t  consul  Cse_param*3  C  f  3 
when  11 

se  -t  0200  C se^params 3  Cf] 
when  15 

se  -t  0150  Cse_para«s3  C  f  3 
when  17 

se  -t  o t  A 0  C se^params 3  C  f  3 
when  18 

se  »t  0200  Cse_para*s3  Cf3 
when  25 

se  -t  bl50  Cse_para*s3  Cf3 

out 

ed  Cf] 


The  first 
In  the  she 
was  used  t 
then  sele 
**e  proper 
with  the 
natch  occu 
•when*  Is 
after  the 
nano  Is  pr 
taken  as 
the  end  of 
nand  sele 
line  edlto 
the  ease  o 
Ing  any  us 


•If*  command  sets  the  remembered  file  name  (stored 
ll  variable  • f • >  In  the  same  fashion  that  •ssr* 
o  set  the  search  rule  (above)*  The  *case»  command 
cts  from  the  terminals  It  recognizes  and  Invokes 
text  editor*  The  argument  of  *case»  Is  compared 
arguments  of  successive  *when*  commands  until  a 
rs*  In  which  case  the  group  of  command*  after  the 
executed!  If  no  match  occurs*  then  the  commands 
•out*  command  will  be  executed.  (If  no  *out*  com- 
esent*  and  no  match  occurs*  then  no  action  Is 
a  result  of  the  *case**>  The  »esac*  command  marks 
the  control  structure*  In  *c**  the  *casef  com¬ 
ets  either  •se*  (the  screen  editor)  or  *ed*  (the 
r)«  and  Invokes  each  with  the  proper  arguments  (In 
f  *se**  Identifying  the  terminal  type  and  speclfy- 
er-dependent  personal  parameters)* 


The  *goto*  command  may  be  used  to  set  up  a  loop  within  a 
command  file*  For  example*  the  following  command  file  will 
count  from  1  to  10: 

•  bogus  command  file  to  show  computers  can  count 
declare  1=1 


:  loop 
1 

set  1  =  Ceval  1  ♦  13 
If  Ceval  1  <=  103 
aoto  loop 
fl 


In  actual  experience*  little  need  has  been  found  for  loops 
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within  command  files*  thus  the  need  for  this  contrived  exam¬ 
ple. 


4.3.2  Stull  capital  ilElilln 


Several  special  shell  variables  are  used  to  control  the 
operation  of  the  comaano  Interpreter.  The  following  table 
Identifies  these  variables  and  gives  a  short  explanation  of 
the  function  of  each. 

VdllAfeU  uUDtilfiD 

_c1_neme  This  varlaole  Is  used  to  select  a  command 

Interoreter  to  be  executed  when  the  user 
enters  the  Subsystem.  It  should  be  set  to 
the  full  pathname  of  the  command  Interpreter 
desired.  The  default  value  Is  "/b^n/sh". 


erase  This  variable  may  be  set  to  a  tingle  charac¬ 

ter  or  an  ASCII  mnemonic  for  n  character  to 
be  used  as  the  "erase."  or  character  delete, 
control  character  for  Subsystem  terminal  In¬ 
put  processing.  The  change  In  erase  charac¬ 
ter  becomes  effective  only  after  the  Sub¬ 
system  Is  re-entered  and  the  Initialization 
routines  read  the  shell  variable  storage 
file. 


_hel lo 


kill 


prompt 


„quote_opt 


This  variable.  If  present.  Is  used  as  the 
source  of  a  command  to  be  executed  whenever 
the  user  enters  the  Subsystem.  It  Is 
frequently  used  tc  Implement  memo  systems, 
supply  system  status  Information,  and  print 
pleasing  messaqes-of-the-day. 

This  v .Triable  may  be  set  to  a  single  charac¬ 
ter  or  an  ASCII  mnemonic  for  a  character  to 
be  used  as  the  "kill."  or  line  delete, 
control  character  for  Subsystem  terminal  In¬ 
put  processing.  The  change  In  kill  character 
becomes  effective  only  after  the  Subsystem  Is 
re-entered  and  the  Initialization  routines 
read  the  shell  variable  storage  file. 

This  variable  contains  the  prompt  string 
printed  by  the  command  Interpreter  before  any 
command  read  from  the  user*t  terminal.  The 
default  value  Is  a  right  bracket  <3>. 

This  variable.  If  set  to  the  value  "YES", 
causes  automatic  quotation  of  each  line  of 
program  output  used  1h  a  function  call.  It 
Is  mainly  provided  for  compatibility  with  an 
older  version  of  tjie  command  Interpreter, 
which  performed  the  quotlnq  automatically. 
The  program  ’quote*  may  be  used  to  explicitly 
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force  quotation* 

search^rule  This  variable  contains  a  sequence  of  comma- 
separated  elements  that  controt  the  procedure 
used  by  the  command  Interpreter  to  locate  the 
object  code  for  a  command.  Each  e'ement  Is 
cither  (1)  the  flag  *A1nt"*  meanlnq  the  com¬ 
mand  Interpreter's  table  of  Internal  com¬ 
mands*  (2)  the  flag  "*v»r*«  meaning  the 
user’s  shell  variables*  or  (.’ >  a  template 
containing  the  character  ampersand  ( S.)  *  mean¬ 
ing  a  particular  directory  or  file  In  a 
directory.  In  the  last  case*  the  cornano 
name  specified  by  the  user  Is  substituted 
Into  the  template  at  the  point  of  the  .amper¬ 
sand*  hopefutly  providing  a  full  pathname 
that  locates  the  object  code  needed. 


4.3.3  CmUllttO 

This  concludes  the  Application  Notes  section. 


-) 
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APPENDIX  5 
E0IT0R 

GEORGIA  TECH  SOFTWARE  TOOLS  SUBSYSTEM 


The  Software  Tools  Subsystem  provides  two  editors*  *ed»  and 

♦  se  •  ♦  The  major  difference  between  the  two  editors  Is  that 

♦  se  •  allows  the  user  to  view  a  window  of  text  during  the 
editing  session*  To  enhance  the  window  feature*  *se*  also 
orovldcs  some  additional  capabilities*  for  example  soeclal 
characters  for  controlling  the  position  of  the  cursor*  The 
basic  editing  commands  available  on  both  editors*  though* 
are  Identical* 


♦Ed*  Is  an  Interactive  program  that  can  be  used  for  the 
creation  and  modification  of  "text"*  "Text"  may  be  any  col¬ 
lection  of  character  data*  such  as  a  report*  a  progr.im*  or 
data  to  be  used  by  a  program.  The  nature  of  the  next  few 
sections  Is  that  of  a  tutorial*  and  os  such*  a  steo-by-steo 
journey  through  an  editing  session* 


9.1.1  SUlllllfl  AO  tailing  SlUlflQ 

Since  you  are  In  the  Subsystem*  the  command  Interpreter 
should  have  just  printed  the  prompt  "3".  To  enter  the  text 
editor*  tyoe 

]  ed  (followed  by  a  newline) 

(Throughout  this  Introduction*  boldface  Is  used  to  Indicate 
Information  typed  by  the  user.)  Tou  are  now  In  the  editor* 
ready  to  go.  Note  that  *ed*  does  not  print  any  prompting 
Information*  this  quiet  behavior  Is  preferred  by  experienced 
users,  (if  you  would  like  a  prompt*  It  can  be  provided;  try 
the  command  "op/orompt/".) 

At  this  oolnt*  *ed*  Is  waiting  for  Instructions  from  you. 
Tou  can  Instruct  *ed*  by  using  "commands"*  which  are  single 
letters  (occasionally  accompanied  by  other  Information* 
which  you  will  see  shortly). 


9.i.s  touting  Iiil  z  tot  tagtoti  fiamnti 

The  first  thing  that  you  will  need  Is  text  to  edit.  Working 
with  *ed*  Is  like  working  with  a  blank  sheet  of  paoer?  you 
write  on  the  paper*  alter  or  add  to  what  you  have  written* 
and  either  file  the  paoer  away  for  further  use  or  throw  It 
away.  In  *ed*  terminology*  the  blank  sheet  of  paper  you 
start  with  Is  called  a  "buffer.*  The  buffer  Is  emoty  when 
you  start  editing.  All  editing  operations  take  place  In  the 
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buffer!  nothing  you  do  can  affect  any  file  unless  you  make 
an  explicit  request  to  transfer  the  contents  of  the  buffer 
to  a  file* 

So  the  first  preblea  reduces  to  finding  a  way  to  put  text 
Into  the  buffer*  The  "append*  coanana  Is  used  to  do  this! 

a 

This  co»*and  appends  (aods)  text  lines  to  the  buffer*  as 
they  are  typed  In* 

To  put  text  Into  the  buffer*  simply  type  It  In*  terminating 
each  line  with  a  newline! 

The  quick  brown  fox 
Jumps  over 
the  lacy  dog* 


To  stop  entering  text*  you  must  enter  a  line  containing  only 
a  period*  laaedlately  followed  by  a  newline*  as  In  the  last 
line  above*  This  tells  *ed*  that  you  are  finished  writing 
on  the  ouffer*  and  are  ready  to  do  soae  editing. 

The  buffer  now  contains! 

The  quick  brown  fox 
Ju*os  over 
the  lacy  doq* 

neither  the  append  command  nor  the  final  period  are  Included 
■in  the  ouffer  -  Just  the  text  you  typed  in  between  then* 


>•1*3  M  Lilian  UU  &JQ  A  lilt  Z  ill  if  lit  IflAAAQd 

Now  that  you  have  some  text  In  the  buffer*  you  need  to  know 
how  to  save  It.  The  write  coaruMd  "w"  Is  used  for  this 
purpose.  It  Is  used  like  this! 

w  file 

where  "file"  Is  the  naac  of  the  file  used  to  store  what  you 
Just  tyoed  In.  The  write  command  cobles  the  contents  of  the 
buffer  to  the  named  file*  destroying  whatever  was  previously 
In  the  file.  The  buffer*  however*  Is  untouched*  whatever 
rou  tyoeo  In  Is  still  there*  To  Indicate  that  the  transfer 
of  data  was  successful*  «ed*  types  out  the  number  of  line.-! 
written.  In  this  example*  *ed*  would  type! 


It  Is  advisable  to  write  the  contents  of  the  buffer  out  to  a 
Tile  -periodically*  to  Insure  that  you  will  have  an  up-to- 
date  version  In  case  of  some  terrible  catastrophe  dike  a 
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syste*  crash)* 


5"*"*  EiPllbApa  Ufi  Z  JUlt  a  All  tflUlPfl 

Now  that  you  have  saved  your  text  In  a  filet  you  nay  wish  to 
lesve  the  editor*  The  "quit"  connand  "a"  1*  provided  for 
this*. 

d 

The  nest  thing  you  see  should  be  the  "3"  pronpt  from  the 
$ubsyate«  cosnond  Interpreter*  If  you  did  not  write  out  the 
contents  of  the  buffert  the  editor  will  respond: 


(not  saved) 

This  Is  to  renlnd  you  to  write  out  the  buffert  so  that  the 
results  of  your  editing  session  will  not  be  lost*  If  you 
Intended  that  the  buffer  be  dlscardedt  Just  enter  "q"  again 
and  *ed*  will  throw  away  the  buffer  and  terminate* 

When  you  receive  the  "3"  proapt  frois  the  Subsyste*  coneand 
Interpreter*  the  buffer  has  been  thrown  away!  there  Is  ab¬ 
solutely  no  way  to  recover  It*  If  you  wrote  the  contents  of 
the  buffer  to  a  file*  then  this  1*  of  no  concern!  If  you  did 
not*  It  «ay  aean  disaster* 

To  check  If  the  test  you  typed  In  Is  really  In  the  file  you 
wrote  It  to*  try  the  following  coaaand: 

3  cat  file 

where  "file"  Is  tbe  name  of  the  flic  given  with  the  "w"  cor- 
«and*  ("Cat"  Is  a  Subsystem  cosmand  that  can  be  used  to 
print  files  on  the  terminal*  If*  for  esaaolc*  you  wished  to 
print  your  file  on  the  line  printer*  you  could  say: 

3  pr  flit 

ano  the  contents  of  "file"  would  be  queued  for  printing*) 


3.1.5  attains  liiti  z  Hit  Enltr  mmn 

Of  course*  »ott  of  the  t1#e  you  will  not  bjp  entering  text 
Into  the  buffer  for  the  first  tlae*  You  need  a  way  to  fill 
the  buffer  with  the  contents  of  soae  file  that  already 
exists*  so  that  you  can  aodlfy  It*  This  Is  the  purpose  of 
the  "enter*  connand  "e* I  It  enters  the  contents  of  a  file 
Into  the  buffer.  To  try  out  "enter*"  you  asust  first  get 
back  Into  the  editor: 

3  ed 
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"Cnter"  It  uted  like  this: 

e  flit 

"FHe"  1*  the  name  of  a  file  to  be  read  Into  the  buffer. 

Note  that  you  are  not  rettrlcted  to  editing  filet  In  the 
current  directory*  you  may  alto  edit  files  belonging  to 
other  users  (provided  they  have  given  you  permission). 
Mies  belonging  to  other  users  must  oe  Identified  by  their 
•full  pathname "  (discussed  fully  In  P£i*£I  Lilt  £Xli£2 
--  ill  flL*££*iCE,«  Cor  example*  to  edit  a  file  named 
■document"  belonging  to  user  "to**"  you  would  enter  the  fol¬ 
lowing  command? 

e  /tom/document 

After  the  f*.le*s  contents  are  copied  Into  the  buffer*  ’ed* 
prints  the  number  of  lines  It  read.  In  our  example*  the 
buffer  would  now  contain? 

I  he  quick  brown  fox 
Jumos  over 
the  lazy  dog. 

If  anything  at  all  Is  present  In  the  buffer*  the  "e"  command 
destroys  It  before  readlna  In  the  named  file. 

As  a  natter  of  convenience*  •ed*  remembers  the  file  name 
specified  on  the  last  "e"  command*  so  you  do  not  have  to 
specify  i  file  name  on  the  "w"  command.  With  these 
orovlslont*  a  common  ealtlna  session  looks  like 

1  ed 
e  file 

tedlt 1no3 

w 

d 

The  "file"  command  ( • f • >  Is  available  for  finding  out  the 
remembered  flte  name.  To  print  out  the  name*  Just  type? 

f 


You  might  also  want  to  check  that 

3  ed  file 

Is  exactly  the  same  as 

)  ed 
e  file 

That  Is*  *ed*  will  perform  an  "e"  command  for  you  If  you 


Georol a  Institute  of  Technology 


COBOL  Workbench 


Appendix  5  EDITOR  Page  195 


give  it  a  file  name  on  the  command  line* 


5*1*4  fcccftii  z  Hut  Auitx  tamod 

Occasionally*  an  error  of  some  kind  will  be  encountered. 
Usually*  these  are  caused  by  misspelled  file  names*  although 
there  are  other  possibilities.  Whenever  an  error  occurs* 
*ed*  types 


Although  this  is  rather  cryptic*  it  is  usually  clear  what 
caused  the  problem.  If  you  need  further  explanation*  Just 
enter  "?•  and  *ed*  will  resoond  with  a  one-line  explanation 
of  the  error.  Tor  example*  if  the  last  command  you  typed 
was  an  "e"  command*  ’ed*  is  probably  saying  that  it  could 
not  lind  the  file  you  asked  for.  You  can  find  out  'or  sure 
by  entering  "?"* 


t  myfllt 

t  ? 

i  * 

I  can’t  open  the  file  to  read 

t  ■» 

Except  for  the  messages  in  reponse  to  •?"*  »ed*  rarely  qives 
j  other*  more  verbose  error  messages!  If  you  should  see  one  of 

|  i  these*  the  best  course  of  action  is  to  report  it  to  someone 

who  maintains  the  editor. 


c  . 


t 


(  ' 


S.I.?  Etiniinfl  UU  -  Hit  Cilal  tatwd 

You  are  likely  to  need  to  print  the  text  you  hove  typed  1r.* 
to  check  it  for  accuracy*  The  "print*  command  "p“  Is 
available  to  do  this,  "p"  is  different  from  the  commands 
seen  thus  fart.  "e"»  "w"»  and  "a"  have  been  seen  to  work  on 
the  whole  buffer  at  once.  For  a  small  file*  It  might  be 
easiest  to  orint  the  entire  buffer  Just  to  check  on  some  few 
lines*  but  for  very  large  files  this  is  clearly  impractical. 
The  "p"  command  therefore  accepts  "line  numbers"  that  in¬ 
dicate  which  lines  to  print.  Try  the  following  experiment: 

T  ad  file 
lp 

The  Quick  brown  fox 
3p 

the  lazy  dog. 

1  »2|> 

The  quick  brown  fox 
Jumps  over 

l«3p 

The  quick  brown  fox 
Jumps  over 
the  lazy  dog. 


1 


i 

V 


$ 

ft 

1 


4 


A 

i 


i 

% 
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"lp"  tells  *ed*  to  print  lint  1  ("The  quick  brown  ton**). 
■3p"  says  to  print  the  third  lint  ("the  lazy  dog*")*  *l*2p* 
tell*  *ed»  to  print  the  first  MrftMflh  the  second  lines*  and 
"l«3o"  says  to  print  the  first  thfgirfph  the  third  lines* 
Suppose  we  want  to  print  the  last  line  In  the  buffer*  but  we 
don’t  know  what  Its  number  Is*  ’Ed*  provides  an  abbrevia¬ 
tion  to  specify  the  last  line  In  the  buffer? 

ip 

the  lazy  dog. 

Thr  dollar  sign  can  be  used  Just  like  a  number*  To  print 
everything  In  the  buffer*  we  could  type? 

l»Sp 

The  quick  brown  f ox 
jumps  over 
the  lazy  dog* 


If  for  sore  reason  you  wont  to  stop  the  printing  before  It 
Is  done*  press  the  BREAK  key  on  your  terminal*  If  you 
receive  no  response  from  BREAK*  »ed»  Is  waiting  tor  you  to 
enter  a  command.  Otherwise*  *ed*  will  respond  with 

? 

and  wait  for  your  nest  command* 


s.i.s  Ban  Saiall&iltd  Lint  Myfctu 

•Ed*  has  several  ways  to  specify  lines  other  than  Just  num¬ 
bers  ants  "1"*  Try  the  following  command: 

P 

the  lazy  dog* 

•Ed*  prints  the  last  line*  Doe*  fed*  always  print  the  last 
line  when  It  Is  given  an  unadorned  "p"  command?  No*  The 
"o"  command  by  Itself  prints  the  "current"  line*  The 
•current"  line  Is  the  last  line  you  have  edited  In  any  w«y. 
(A s  a  matter  of  fact*  the  Inst  thing  we  did  was  to  print  all 
the  lines  In  the  buffer*  so  the  last  line  was  edited  bv  be- 
Ino  orlnted*)  ’Ed*  allows  you  to  use  the  symbol  (read 

"dot")  to  represent  the  current  line*  Thus 

•  P 

the  lazy  dog. 

Is  the  sa^e  as 

*  *  *P 

the  lazy  dog. 
which  Is  the  same  as  Just 
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the  lazy  dog. 


"."  can  be  used  in  many  ways.  For  example* 


1  *2p 

The  Quick  brown  fox 
jumps  over 

1  *»P 

The  quick  brown  fox 
Jumps  over 

•  *tp 

Jumps  over 
the  lazy  dog. 


|  This  exarple  shows  how  to  print  all  the  lines  up  to  the 

«  current  line  <l*.p>  or  alt  the  lines  from  the  current  line 

!  to  the  end  of  the  buffer  (.»$p).  If  for  some  reason  you 

would  like  to  know  the  number  of  the  current  line*  you  can 
type 


3 


•* 


and  *ed*  will  display  the  number.  (Note  that  the  last  thing 
we  did  was  to  print  the  last  line*  so  the  current  line 
became  line  3.) 

Is  not  particularly  useful  when  used  alone.  It  becomes 
much  more  important  when  used  In  "line-number  expressions." 
Try  this  experiment: 

.-lp 

Jumps  over 

".-1"  means  "the  line  that  is  one  line  before  the  current 
line." 


•  ♦Ip 

the  lazy  dog* 

".♦1"  means  "the  line  that  Is  one  line  after  the  current 
line," 


••2*.-lP 

The  quick  brown  fox 
Jumps  over 


3 


'  3 

*.-2«.-1p"  means  "print  the  lines  from  two  lines  before  to  \ 

one  line  before  the  current  line."  '  f| 

;  i 

, 
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You  can  also  use  "$"  In  line-number  expressions: 

*-lp 

jumps  over 

"*-lp"  mean s  "print  the  line  that  Is  one  line  before  the 
last  line  In  the  buffer  (the  next  to  the  last  line)*" 

Some  abbreviations  are  available  to  help  reduce  the  amount 
of  typing  you  have  to  do.  Typing  a  newline  by  Itself  Is 
equivalent  to  typing  ".*lp"t  typing  an  uo  arrow*  "*"«  fol¬ 
lowed  by  a  newline  Is  eoulvalent  to  typing  "*-lp"$  and  typ¬ 
ing  a  line-number  expression  followed  by  a  newline  Is 
equivalent  to  typing  that  line-number  expression  followed  by 
"p".  Examples: 

(type  a  newline  by  Itself) 
the  lazy  dog* 

A 

Jumps  over 

1 

The  quick  brown  fox 


It  eight  be  worthwhile  to  note  here  that  all  commands  expect 
line  numbers  of  one  form  or  another.  If  none  are  supplied* 
•ed*  will  use  default  values.  Thus* 

w  file 

Is  equivalent  to 

l«Sw  file 

and 

« 

Is  equivalent  to 

•  a 

(which  means*  append  text  after  the  current  line.) 


5*1.9  RslillM  llnu 


As  yet*  you  have  seen  no  way  of  removing  lines  that  are  no 
longer  wanted  or  needed.  To  do  this*  use  the  "delete"  com¬ 
mand  "d": 


1  *2d 


Deletes  the  first  through  the  second  lines,  "d"  expects 
line  numbers  that  work  In  the  same  way  as  those  specified 
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for  "p"«  deleting  one  line  or  any  range  of  lines* 
d 


delete* 

".«.d". 


only  the  current  line.  It  Is  the  same  as  ".d"  or 


After  a  deletion*  the  current  line  pointer  Is  left  pointing 
to  the  first  line  after  the  group  of  deleted  lines*  unless 
the  last  line  In  the  buffer  was  deleted.  In  this  case*  the 
current  line  Is  the  last  line  f Qf e  the  group  of  deleted 
lines. 


s.i.io  ini  EiiUm 

Frequently  It  Is  desirable  to  be  able  to  find  a  particular 
"pattern*  In  a  piece  of  text.  For  example*  suppose  that 
after  proofreading  a  report  you  have  typed  In  using  »ed*  you 
find  a  spelling  error.  There  must  be  an  easy  way  to  find 
the  Misspelled'  word  In  the  file  sc  It  can  be  corrected.  One 
way  to  do  this  It  to  count  all  the  lines  up  to  the  line 
containing  the  error*  so  that  you  can  give  the  line  number 
of  the  offendlno  line  tp,  *ed».  Obviously*  this  way  Is  not 
very  fast  or  efficient.  *Cd*  allows  you  to  "search"  for 
patterns  of  text  (like  words)  by  enclosing  the  pattern  In 
slashes  t 


/Jump*/ 

Jumps  over 


•Cd*  looks  for  the  pattern  you  specified*  and  Moves  to  the 
first  line  which  contains  the  pattern,  fote  that  If  we  had 
typed 

/Juaptd/ 


•ed*  Informs  us  that  It  could  not  find  the  pattern  we 
wanted. 

j  *Cd*  searches  iaiMAIlf  from  the  current  line  when  It  attempts 

|  to  find  the  pattern  you  specified.  If  »edf  reaches  the  last 

line  without  seeing  the  pattern*  It  "wraps  around"  to  the 
first  line  In  the  file  and  continue*  searching  until  It 
either  finds  the  pattern  or  gets  back  to  the  line  where  It 
j  started  (line  This  procedure  ensures  that  you  will 

t  get  the  "next"  occurrence  of  the  pattern  you  were  looking 

|  for*  and  that  you  will  not  «1s*  any  occurrences  because  of 

your  current  position  In  the  file. 


SuDpcse*  however*  that  you  do  not  wish  to  find  the  "next" 
occurence  of  a  word*  but  the  pf-qy  19VI  occurrence  of  a  word. 
Very  few  text  editors  provide  this  capability!  however*  »ed* 
Makes  It  simple.  Just  surround  the  pattern  with  back¬ 
slashes  J 
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\qu1cfcA 

The  quick  brown  fox 

Remember:  backslashes  -  search  backward*  The  backward 

search  (or  backscan«  as  It  Is  sometimes  called)  wraps  around 
the  file  In  a  manner  similar  to  the  forward  search  (or 
scan)*  The  search  begins  at  the  line  before  the  current 
line*  proceeds  until  the  first  line  of  the  file  Is  seen* 
then  begins  at  the  last  line  of  the  file  and  searches  up 
until  the  current  line  Is  encountered*  Once  again*  this  Is 
to  ensure  that  you  do  not  alas  any  occurrences  of  a  pattern 
due  to  your  current  position  In  the  file* 

♦Ed*  also  provides  more  powerful  pattern  matching  services 
than  simply  looking  for  a  given  string  of  characters*  (A 
note  to  beginning  users:  this  section  may  seem  fairly  com¬ 
plicated  at  first*  and  Indeed  you  do  not  really  need  to  un¬ 
derstand  It  completely  for  effective  use  of  the  editor* 

However*  the  results  you  might  get  from  some  patterns  would 

be  mystifying  If  you  were  not  provided  with  some  ex¬ 

planation*  so  look  this  over  once  and  move  on*) 

The  oattern  that  may  appear  within  slashes  (or  backslashes) 
is  called  a  "regular  expression*"  It  contains  characters  to 
look  for  and  special  characters  used  to  perform  other 
operations*  The  following  characters 

x  ?  i  c  •  a  < 

have  special  seanlna  to  *ed*I 

X  Beginning  of  line.  The  "X"  character  appearing  as 
the  first  element  In  a  pattern  matches  the  begln- 
nlna  of  a  line.  It  Is  most  frequently  used  to 
locate  lines  with  some  string  at  the  very  begin¬ 
ning?  for  example* 

/XThe/ 

finds  the  next  line  that  begins  with  the  word 
"The"*  The  percent  sign  has  Its  special  meaning 
only  If  It  Is  the  first  element  of  the  pattern! 
otherwise*  It  Is  treated  as  a  literal  percent 
sign. 

?  Any  character.  The  question  mark  In  a 

regular  expression  matches  qnv  character  (except  * 
beglnnlng-of ~l Ine  or  a  newline)*  It  can  be  used 
like  this: 


/a?b/ 

to  find  strings  like 

a*b 

a-b 
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a  b 

arb It  rar y 

However*  "?"  is  most  often  used  with  the 
"closure*  operator  "*•  (see  below)* 

t  End  of  line*  The  dollar  sign  appearing  as  the 
last  element  of  a  pattern  matches  the  newline 
character  at  the  end  of  a  line*  Thus* 

/today*/ 


can  dc  used  to  find  a  line  with  the  word  "today* 
at  the  very  end*  Similar  to  the  percent  sign*  the 
dollar  sign  has  no  special  meaning  in  positions 
other  than  at  the  end  of  a  pattern* 


Cl  Character  classes*  The  square  brackets  are  used 
to  match  "classes"  of  characters*  For  example* 

/CA-23/ 

wilt  find  the  next  line  containing  a  capital  tet¬ 
ter* 

/XCabcxyz  3/ 

will  find  the  next  line  beginning  with  an  a*  b*  c« 
x«  y»  or  z*  and 

/C ”0-9  3/ 

wilt  find  the  next  line  which  contains  a  non- 
digit*  Character  classes  are  also  frequently  used 
with  the  "closure"  operator 


*  Closure*  The  asterisk  is  used  to  mean  "any  number 
of  repetitions  Cincludinq  zero)  of  the  previous 
oattern  element  (one  character  or  a  character 
class  in  brackets)*"  Thus* 


/o9*b/ 

will  find  lines  containing  an  "a"  followed  by  any 
number  of  characters  and  a  "b"*  For  examole*  the 
following  lines  will  be  matched: 

ab 

abnormal 

Recording  Media*  by  Dr*  Joseph  P*  Gunchy 
At  another  example* 


* 


/%**%/ 

will  match  only  those  lines  containing  all  eoual- 
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signs  (or  nothing  at  all)*  If  you  wish  to  ensure 
that  only  non-empty  lines  are  matched*  use 

/*==»*/ 

Always  remember  that  (closure)  will  match  ££££ 
or  more  repetitions  of  an  element* 

Escape*  The  "at*  sign  has  special  meaning  to  both 
*ed*  and  the  Subsystem  I/O  routines*  It  Is  the 
"escape"  character*  which  Is  used  to  prevent 
Interpretation  of  a  special  character  which  fol¬ 
lows*  (note  that  to  enter  a  single  *8*  from  a 
terminal*  you  must  type  two!  the  Subsystem  I/O 
routines  remove  one  in  the  process  of  interpreting 
escaped  characters*)  Suppose  you  wish  to  locate  a 
line  containing  the  string  "a  •  b"*  You  may  use 
the  following  command: 

/a  38*  b/ 

(Note  that  inn  "at*  signs  are  required  to  pass  one 
"at"  sign  to  the  editor.)  The  "at"  sign  "turns 
off"  the  special  meaning  of  the  asterisk*  so  it 
can  be  used  as  an  ordinary  test  character*  You 
may  have  occasion  to  escape  any  of  the  regular  ex¬ 
pression  metacharacters  tt«  ?»  s»  C*  •*  a*  or  l) 
or  the  slash  Itself*  For  example*  suppose  you 
wished  to  find  the  next  occurrence  of  the  string 
"1/2".  The  command  you  need  1st 

/ 1 58/2/ 


U  Pattern  tags*  As  seen  In  the  next  section*  It  Is 
sometimes  useful  to  remember  what  part  of  a  line 
was  actually  matched  by  a  pattern*  By  default* 
the  string  matched  by  the  entire  pattern  Is  remem¬ 
bered.  It  Is  also  possible  to  remember  a  string 
that  was  matched  by  onty  a  part  of  a  pattern  by 
enclosing  that  oart  of  the  pattern  In  braces* 
Hence  to  find  the  next  line  that  contains  a  Quoted 
string  and  remember  the  text  between  the  quotes* 
we  night  use 

/"{?•)"/ 

If  the  line  thus  located  looked  like  this 

This  Is  a  line  containing  r<  "Quoted  string" 

then  the  text  remembered  as  matching  the  tagged 
nart  of  the  pattern  would  be 

quoted  string 
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The  last  Important  thing  you  util  need  to  know  about  pat¬ 
terns  Is  the  use  of  the  "default"  pattern.  *! d*  remembers 
the  tast  regular  expression  used  In  any  command*  to  save  you 
the  trouble  of  retyping  It.  To  access  the  remembered  pat¬ 
tern.  simply  use  an  "empty"  string.  For  example,  the  fol¬ 
lowing  sequence  of  commands  could  be  used  to  step  throuqh  a 
file,  looking  for  each  occurrence  of  the  string  "ICS": 

/ICS/ 

// 

// 

(and  so  on) 


One  last  comment  before  leaving  pattern  searching.  The 

constructs 

/pattern/ 

NpatternN 

arc  not  separate  commandsi  they  are  components  of  line  num¬ 
ber  expressions.  Thus,  to  print  the  line  after  the  next 
line  containing  "tane".  you  could  say 

/tape/mlp 

Or.  to  print  a  range  of  lines  from  one  before  to  one  after  a 
line  with  a  given  pattern,  you  could  use  ' 

/pattern/-! . /pa t tern/e Ip 


5.1.11  Banna  sufaiinuiigm  z  nut  SiikiUiiiii  samoa 

This  Is  one  of  the  most  used  editor  commands.  The  "sub¬ 
stitute"  command  Is  used  to  make  small  changes  within 

lines,  without  the  need  of  retyping  them.  It  Is  used  like 
this: 

starting-line. ending-line  s  /pattern/new-stuf f / 

For  Instance,  suppose  our  buffer  looks  like  this: 

l.*P 

The  quick  brown  fox 
Jumps  over 
the  lazy  dog. 

To  change  "Jumps"  to  "Jumped." 

2s/Juaps/Juapad/p 

Jumped  over 

Mote  the  use  of  the  trailing  "p"  to  print  the  result.  If 
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the  "o"  had  been  omitted*  the  change  would  have  been  per¬ 
formed  (In  the  buffer)  but  the  changed  line  would  not  have 
been  printed  out# 

If  the  last  string  specified  In  the  substitute  command  Is 
empty*  then  the  pattern  found  Is  deleted: 

s/ jumped//? 

over 

s/%  •  /  Jumps  /p 
Jumps  over 

Recalling  that  a  missing  pattern  means  "use  the  last  pattern 
specified*"  try  to  explain  what  the  following  commands  do! 

s///p 

Jumps  over 
s //  to 

Jumps  over 

(Note  that*  like  many  other  commands*  the  substitute  command 
assumes  you  want  to  work  on  the  current  line  If  you  do  not 
specify  any  line  numbers*) 

What  If  you  want  to  change  "over*  Into  "over  and  over"?  We 
might  use 

s/over/over  and  over/p 

Junos  over  and  over 

to  accomplish  this*  There  Is  a  shorthand  notation  for  this 
kind  of  substitution  that  was  alluded  to  briefly  In  the  last 
section.  (Recall  the  discussion  of  "tagged"  paterns*)  Oy 
default*  the  part  of  a  line  that  was  matched  by  the  whole 
pattern  Is  remembered*  This  string  can  then  be  Included  In 
the  replacement  string  by  typing  an  ampersand  (*l*)  In  the 
desired  position.  So*  Instead  of  the  ceamand  In  the  last 
example* 

s/ovar/l  and  X/ 

could  have  been  used  to  get  the  same  result*  If  portion  of 
the  pattern  hod  been  tagged*  the  text  matched  by  the  tagged 
part  In  the  replacement  could  be  reused  by  typing  "881*: 

a/ Jump {?• )/ vault 881 /p 

vaults  over  and  over 

It  Is  possible  to  tag  up  to  nine  parts  of  a  pattern  using 
braces*  The  text  matched  by  each  tagged  part  may  then  be 
useo  In  a  replacement  string  by  typing 

*8n 

where  n  corresponds  to  the  nth  *{*  In  the  pattern#  What 
does  the  fallowing  command  do? 
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*/<C"  30  (TO/882  881/ 


Final  words  on  substitute:  the  slashes  are  known  as 

"delimiters"  and  nay  be  replaced  by  any  other  character  ex¬ 
cept  a  newline*  as  long  as  the  same  character  Is  used 
consistently  throughout  the  command*  Thus* 

sfvaultsftvaultedtp 

vaulted  over 

Is  legal*  Also*  note  that  substitute  changes  only  the  first 
occurrence  of  the  oattern  that  It  finds*  If  you  wish  to 
change  all  occurrences  on  a  line*  you  may  append  a  "o"  (for 
"global")  to  the  command*  like  this: 

»/  /"/gp 

vault ed*over 


5.i.i2  Llui  siiiaau  nut  laitillfloi 

Two  "abbreviation"  commands  are  available  to  shorten  common 
operations  applying  to  changes  of  entire  lines.  These  arc 
the  "change"  command  "c"  ana  the  "Insert"  command  "1". 

The  change  command  Is  a  comb Inat Ion  of  delete  and  append. 
Its  format  Is 

start ing-l 1ne«ending-l  Ine  c 

This  comnand  deletes  the  glvr-n  range  of  lines*  and  then  goes 
Into  append  mode  to  obtain  text  to  replace  them.  Append 
mode  works  exactly  the  same  way  as  It  does  for  the  "a"  com- 
nand*  Input  Is  terminated  by  a  period  standing  alone  on  a 
line*  fxamlne  the  following  editing  session  to  see  how 
change  mloht  be  used: 

i«*c 

Fd  Is  an  interactive  program  used  for 
the  creation  and  modification  of  "text. 

• 

c 

the  creation  and  modification  of  "text." 

■Text"  may  tie  any  collection  of  character 
data* 


As  you  can  see*  the  current  line  Is  set  to  the  last  tine 
entered  In  append  mode. 
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The  other  abbreviation  command  1*  •I**  M*  It  very  closely 
related  to  "a*l  In  fact*  the  following  relation  holds: 

starting-line  1 

is  the  same  as 

starting-line  -  1  a 

In  short*  "I*  Inserts  test  before  the*  specified  line* 
whereas  "a*  Inserts  test  niiftc  the  specified  line. 


5.1 .13  Hqwlna  Xtli 

Throughout  this  Introduction*  we  have  concentrated  on  what 
*ay  be  called  ■In-place*'  editing.  The  other  type  of  editing 
commonly  used  is  often  called  "cut-and-paste*  editing.  The 
move  cona and  Is  provided  to  facilitate  this  kind  of 
editing*  and  works  like  thlst 

start  1ng-Une*end1ng-l1ne  m  af ter-thls-llne 

If  you  wanteo  to  wove  the  last  fifty  lines  of  a  file  to  a 
point  after  the  third  line*  the  command  would  be 

t-49«Sn3 

Any  of  the  line  numbers  *ay*  of  course*  be  full  expressions 
with  search  strings*  arlthactlc*  etc. 

You  say*  If  you  like*  append  a  "p"  to  the  move  command  and 
It  will  print  the  last  line  moved.  The  current  line  Is  sot 
to  the  last  line  moved. 


s.i.i*  itififcii  Camnfli 

The  "\lobal"  cosaand  "g"  Is  used  to  perform  an  editing  com¬ 
mand  on  all  lines  In  the  buffer  that  match  a  certain  pat¬ 
tern.  For  example*  to  print  all  the  lines  containing  the 
word  "editor"*  you  could  type 

g/mdl tor/p 

If  you  wanted  to  correct  some  common  spelling  error*  you 
would  use 


g/old-stuf f /s//n«w-»tuf f fqp 

which  will  make  the  change  In  all  appropriate  lines  and 
print  the  resulting  lines.  Another  example:  deleting  all 
tines  that  begin  with  an  asterisk  could  be  done  this  way: 
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g/X88*/d 


“G*  has  a  companion  command  "x*  (for  "excluoc")  that  per¬ 
forms  an  operation  on- alt  tines  In  the  buffer  that  do  ijfii 
match  a  given  pattern.  For  example*  to  delete  all  lines 
that  do  npt  begin  with  an  asterisk*  use 

x/X88»/d 


"G"  and  "  x*  arc  very  powerful  commands  that  are  essential 
for  advanced  usage*  but  are  usually  not  necessary  for  begin¬ 
ners.  Concentrate  on  other  aspects  of  *ed*  before  you  move 
on  to  tncStlc  global  commands. 


s.i.is  tuiUoA  klaii 

Ourlng  some  types  of  editing*  especially  when  moving  Mocks 
of  text*  It  Is  often  necessary  to  refer  to  o  line  In  the 
buffer  that  Is  far  away  from  the  current  line.  For 
Instance*  say  you  want  to  move  a  subroutine  near  the  begin¬ 
ning  of  a  file  to  somewhere  near  the  end*  but  you  nren’t 
sure  that  you  can  specify  patterns  to  properly  locate  the 
subroutine.  One  way  to  solve  this  problem  Is  to  find  the 
first  line  of  the  subroutine*  then  use  the  command 

/subroutine/ 

subroutine  think 
•  x 

*7 

and  write  down  (or  remember)  line  *7.  Then  find  the  end  of 
the  subroutine  and  do  the  thing: 


* 


/end/ 

end 

•  - 

71 

Now  you  move  to  where  you  want  to  place  the  subroutine  and 
enter  the  command 

*7»71m* 

which  does  exactly  what  you  uant. 


The  problem  here  Is  that  absolute  line  numbers  are  easily  % 
f orqotten*  easily  mistyped*  and  difficult  to  find  In  the  J 
first  place.  It  Is  much  easier  to  haye  *ed*  remember  a  -J 


short  "name"  along  with  each  line*  and  allow  you  to 
reference  a  line  by  Its  name.  In  practice*  It  seems  con¬ 
venient  to  restrict  names  to  a  single  character*  such  as  "h" 
or  "e"  (for  "beginning"  or  "end").  It  Is  not  necessary  for 
a  given  name  to  be  uniquely  associated  with  one  line*  many 
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the  same  name*  In  feet*  at  the  beginning  of 
alt  line*  are  Marked  with  the  tame 


line*  May  bear 
the  editing  session* 
naiet  a  single  space* 

To  return  to  our  example*  using  the  *k*  command*  we  can  Mark 
the  beginning  and  ending  tines  of  the  subroutine  quite 
easily: 

/subroutine/ 

subroutine  think 

kb 

/end/ 

end 

ke 

We  have  now  Marked  the  first 
and  the  second  line  with  *e" 


line  In  the  subroutine  with  "b* 


To  refer  to  names*  we  need  More  line  nueber  expression 
elements;  ">"  and  "<"•  Both  work  In  line  number  expres¬ 
sions  lust  like  "$•  or  "/pattern/"*  The  symbol  ">"  followed 
ay  a  slnole  character  «ark  name  Means  "the  line  number  of 
the  first  line  with  this  name  when  you  search  f pr^ar^f"*  The 
synl-ol  •<"  followed  by  a  single  character  mark  name  Means 
"the  line  number  of  the  first  line  with  this  name  when  you 
search  •  (Just  remember  that  •<*  points  backward 
and  •>*  points  forward*) 

Now  In  our  example*  once  we  locate  the  new  destination  of 
the  subroutine*  we  can  use  "<b*  and  "<e"  to  refer  to  lines 
47  and  7!«  respectively  (remember*  we  marked  them).  The 
•move"  command  would  then  be 

<b«<ea* 


Several  other  features  pertaining  to  nark  names  are  Im¬ 
portant.  First*  the  *k*  command  fctUCSJl  the  current 

You  can  say 


Skx 


(which  marks  the  last  line  with  "x")  and 
changed.  If  you  want  to  mark  a  ranoe  of  lines* 
#and  will  take  two  line  numbers •  For  Instance* 


will  not  be 
the  * k •  ccim- 


5*10ka 

will  mark  lines 
lines  5  through 


5  through  10  with 
10  the  name  "a"). 


(I.e**  give  each  of 


The  *!•  and  apostrophe  commands  also  deal  with  narks. 
Thr  *n*  command  performs  two  functions.  If  It  Is  Invoked 
without  a  mark  name  following  It*  like 
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Sn 

It  wilt  print  the  mark  name  of  the  line*  In  this  case*  It 
would  print  the  mark  name  of  the  last  tine  In  the  file*  If 
the  «n*  command  Is  followed  by  a  mark  name*  tike 

4nq 

It  marks  the  tine  with  that  mark  name*  and  erases  the  marks 
on  any  other  lines  with  that  name.  In  this  case*  line  A  1 5 
marked  with  "q"  and  It  Is  guaranteed  that  no  other  line  In 
the  file  Is  marked  with  "a". 

The  •!*  and  apostrophe  commands  are  both  global  commands 
that  deal  with  mark  names.  The  apostrophe  command  works 
very  much  like  the  *g*  command:  the  apostrophe  Is  followed 
by  a  mark  name  and  another  command  1  the  command  Is  performed 
on  every  line  marked  with  that  name.  For  Instance* 

'•t/f oi/rabbl t / 

will  change  the  first  "fox"  to  "rabbit"  on  every  line  that 
Is  named  "a".  The  *!•  command  works  In  the  same  manner* 
exceot  that  It  performs  the  command  on  those  lines  that  f re 
not  marked  with  the  specified  name*  For  example*  to  delete 
all  lines  not  named  "k"«  you  could  type 

Ikd 


5.1.16  unflaioa  Itilaai  zz  Xh*  tauUt  Samnd 

Unfortunately*  Hurohy’s  Law  ciuarantces  that  If  you  make  a 
mistake*  It  will  happen  at  the  worst  possible  tine  and  cause 
the  greatest  possible  amount  of  damage.  *Cd*  attempts  to 
Drevent  mistakes  by  doing  such  things  as  worklnq  with  a  copy 
of  your  file  (rather  than  the  file  Itself)  and  checking  com¬ 
mands  for  their  plausibility.  However*  If  you  type 

d 

when  you  really  meant  to  type 

a 

*ed»  must  take  Its  Input  at  face  value  and  do  what  you  say. 
It  Is  at  this  point  that  the  "undo"  command  becomes  useful. 
"Undo"  allows  you  to  "undelete"  the  last  group  of  lines*  that 
were  deleted  from  the  buffer.  In  the  last  example*  some 
Inconvenience  could  be  avoided  by  typing 

*ud 

which  restores  the  deleted  line.  (By  default  “undo"  will 
also  delete  the  current  llnel  "ud"  keeps  the  current  line 
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The  problem  that  arises  with  •undo*  Is  the  answer  to  the 
Question  "What  was  the  last  group  of  lines  deleted?"  This 
answer  Is  very  dependent  on  the  Implementation  of  *ed»  ane* 
In  some  cases  Is  subject  to  change*  After  many  commands* 
the  last  group  of  lines  deleted  Is  well-defined*  but 
unspecified.  It  Is  not  a  good  Idea  to  use  the  "undo"  cos* 


aand  after  anything  other  than  *c**  *d*»  or 
*c»  or  *d*  command* 


ud 


After  a 


will  place  the  last  group  of  deleted  lines  aHft£  ihC  EUELtLli 
line.  After  an  command  (which  by  the  way*  deletes  the 
old  line  and  then  reinserts  the  changed  line)* 


u 


- 


will  delete  the  current  line  and  replace  It  with  the  last 
line  deleted  --  It  will  exactly  undo  the  effects  of  the  *s* 
command* 

You  should  be  warned  that  while  "undo"  works  nicely  for 
repairing  «  single  *c»«  *d**  or  •  command*  It  cannot 
repair  the  damage  done  by  one  of  these  commands  under  the 
control  of  a  global  prefix  (*g*»  *x»*  •!•  and  apostrophe). 
Since  the  global  prefixes  perform  their  commands  many  times* 
only  the  very  last  command  performed  by  a  global  prefix  can 
be  repaired. 


5.1.17  small* 

This  concludes  our  tour  through  the  world  of  text  editing. 
For  your  convenience*  a  short  summary  of  all  available  edit¬ 
ing  commands  (many  of  which  were  not  discussed  In  this 
Introduction*  but  which  you  will  undoubtedly  find  useful)  Is 
given  In  the  next  few  sections. 
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editor  Command  Summary 


diioai  Lt£i£  EuniiAan 


• » • 


• » . 


ItS 


•  • 


•  •  • 


• » . 


none 


.  * . 

none 


•  »  • 


*  «  . 


d 

t* 

f 


D 

q 


append  text  after  the  specified  tine 


change*  delete  specified  text*  then  accept  text 
to  replace  It 


delete  specified  range  of  lines 

edit  named  file  (syntax!  e  [filename!) 

print  remembered  file  name  (syntax!  f [ f 1 lename 3) 

( syntax! 


globally  perform  command 

g/pattern/command) 


Insert  text  before  specified  line 


Join  the  specified  lines  Into  a  single  line 
(syntax!  J/str1ng/>.  "string"  Is  Inserted 
between  each  pair  of  lines  Joined. 


m.^rk  lines  with  given 
k<single-character-naae>) 


move  lines  from  one  place  to  another 
f rom-here*to-here  m  thereto!) 


name  (syntax! 

(syntax ! 


print  mark  names  of  specified  lines 


options  command.  Syntax  Includes! 
op/prompt/  to  set  command  prompt 


print  specified  lines 

quit  (exit  the  editor  gracefully) 

Into  the  buffer  (syntax! 


read  a  file 
[filename!) 


substitute  (syntax!  s/chonge-thls/to-thls/Cp!) 


transtit  (syntax!  t/f rom-range/to-range/tp3) • 
Characters  In  the  "from-range*  arc  converted  to 
their  corresponding  characters  In  the 
"to-range". 
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•  «•  u  un-substitute  (restore  lines  that  were  changed 

by  substitution) 

v  overlay!  print  all  line*  In  the  given  range* 
uniting  at  the  end  of  each  line  tor  text  that 
Is  to  oe  appended. 

l«i  w  write  buffer  (syntax:  w  Cfllenamel) 

1*5  x  excludel  converse  of  "g"!  perform  command  on 

all  lines  that  do  not  match  a  given  pattern 
(syntax:  x/pa ttern/command) 

•  *.  y  copy!  reproduce  a  block  of  lines  In  another 

place  (syntax:  f rom-here* to-here  y  after-here) 

.  =  print  value!  value  of  the  line  number 

expression  preceding  the  eouals  slan  Is  printed 
as  a  decimal  Integer,  (syntax:  <express1on>=) 

l*t  *  global  on  mark!  perform  command  on  all  lines 

havlnq  a  given  mark  name  (syntax: 
,<name>co*mand) 

1*1  !  exclude  on  mark*  perform  command  on  all  lines 

that  dc  not  have  a  given  mark  name  (syntax: 
!<n*me>comaand) 
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5.1.17.2  Line  Number  Expressions 


Elements  of  Line  Nuaber  Expressions 


Efiis  iaiyc 


integer 


1 


/pattern/ 


\pat  tern\ 


>name 


Cnane 


expression 


value  of  the  Integer.  (Ext  *4) 

number  of  the  current  line  in  the  buffer 

number  of  the  ,last  line  In  the  buffer 

nuaber  of  the  previous  line  In  the  buffer  (•- 
1) 

nuaber  of  the  next  line  In  the  buffer  that 
matches  the  given  pattern  (Ext  /February/); 
the  search  proceeds  to  the  end  of  the  buffer* 
then  wraps  around  to  the  beginning  and  back 
to  the  current  line 

number  of  the  next  line  In  the  buffer  that 
matches  the  given  pattern*  search  proceeds  In 
reverse*  from  the  current  line  to  line  1* 
then  the  last  line  back  to  the  current  line. 
(Ex;  \January\> 

nuxoer  of  the  next  line  having  the  given  mark 
name  (search  wraps  around*  like  //) 

number  of  the  next  line  having  the  given  mark 
name  (search  proceeds  In  reverse*  In  the  same 
way  as  \\) 

Any  of  the  above  operands  may  be  combined 
with  plus  or  minus  signs  to  produce  a  line 
number  expression.  Plus  signs  may  be  omitted 
If  desired.  (Ex;  /parse/-5*  /lexlcal/^2* 
/lexical/2*  S-5*  .♦(.) 
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5.1.17«3  Pattern  Clamant* 


Suaairy  of  Pattern  Eleeent* 


Li£*£2i 


X  Hatches  the  null  string  at  the  beginning  of  a 

tine.  However*  If  not  the  flrat  element  of  a 
pattern*  Is  treated  as  a  literal  percent 
s  Ion. 

?  Matches  any  single  character  other  than 

newline. 


S 


C  <cc l>  1 


C “<cc l>  3 


a 


vatches  the  newline  character  at  the  eno  of  a 
line.  However*  If  not  the  laat  element  of  a 
pattern*  Is  treated  as  a  literal  dolUr  sign. 

Matches  any  single  character  that  Is  a  member 
of  the  set  specified  by  <ccl>.  <ccl>  may  be 
composed  of  single  characters  or  of  character 
ranges  of  the  form  <cl>-<c2>.  If  character 
ranges  ore  used*  <d>  and  <c2>  must  both 
belong  to  the  digits*  the  upper  case  alphabet 
or  the  lower  case  alphabet. 

Matches  any  single  character  that  Is  not  a 
member  of  the  set  specified  by  <ccl>. 

In  combination  with  the  Immediately  proceed¬ 
ing  oattern  element*  matches  zero  or  more 
characters  that  are  matched  by  that  element. 

Turns  off  the  special  meaning  of  the  Im¬ 
mediately  following  character.  If  that 
character  has  no  special  meaning*  this  Is 
treated  as  a  literal  "S*. 


(<Dottcrn>) 


S 


3<d1g1 t> 


Tags  the  text  actually  matched  by  the  sub¬ 
pattern  speclfed  by  <pattern>  for  use  In  the 
replacement  part  of  a  substitute  command. 

Appearing  In  the  replacement  part  of  a  sub¬ 
stitute  command*  represents  the  text  actually 
matched  by  the  pattern  part  of  the  command. 

Appearing  In  the  replacement  part  of  a  sub¬ 
stitute  command*  represents  the  text  actually 
matched  by  the  tagged  sub-pattern  specified 
by  <a1git>. 
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3.2.  ££ 

♦Se*  work*  much  like  the  regular  editor  *ed*«  ucceptlno  the 
same  command*  with  a  few  differences.  Father  than  display¬ 
ing  only  a  slnqle  line  from  the  file  being  edited  (as  ‘ed* 
does)*  Me*  always  displays  a  "window"  onto  the  file.  In 
order  to  do  this*  »se*  must  be  run  from  a  CRT  terminal  and 
must  be  told  what  sort  of  terminal  It  Is.  This  Is  accom¬ 
plished  through  the  specification  of  a  particular  parameter 
when  ♦so*  Is  Invoked. 


3.2.i  ucaiDAii  Suafiarlid 

•So*  Is  capable  of  being  used  from  a  variety  of  different 
terminals.  Hew  terminal  types  are  easily  auded  by  making 
small  additions  to  the  source  code.  In  general «  all  that  is 
reoulred  of  a  terminal  Is  that  It  have  the  ability  to  home 
the  cursor  (position  It  to  the  upper  left  hand  corner  of  the 
screen)  without  eraslno  the  screen*s  contents*  although  bac¬ 
kspacing*  a  screen  clear  function*  and  arbitrary  cursor 
positioning  are  tremendously  helpful. 

The  terminals  currently  supported  are  the  following: 

adds  AODS  Consul  980.  (This  1*  the  same  a*  "consul" 

below. ) 

ad*Ja  Lear-Siegler  A0H-3A. 

6150  beehive  International  9150. 

b200  Beehive  International  8200. 

eg  Chromatics  Color  Graphics  Terminal. 

consul  ADOS  Consul  980. 

fo*  Perk 1n-tlmer  1100. 

hay  Hayeltlne  1,500  series. 

1*e  Intelligent  Systems  Corporation  8001  Color 

Terminal* 

regent  ADOS  Regent  100. 

sbee  Beehive  Internet  1 onal  Superbee. 

sot  Processor  Technology  Sol  computer  with  software  to 

emulate  a  Beehive  6200. 

tvt  Southwest  Technical  Products  TV  Typewriter  II. 
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5.2.2  EdlUoa  flaUm 


*Se*  allows  the  user  to  set  various  options  which  control 
the  editing  envrlonment •  To  set  an  option,  the  user  must 
specify  the  "option"  <o)  command.  This  consists  of  the  let¬ 
ter  *o»  followed  hy  one  of  the  following  strings  of  charac¬ 
ters  : 


a  causes  absolute  line  numbers  to  be  displayed  In 

the  left-hand  margin  of  the  screen.  Default 
oehavlor  Is  to  display  upper-case  letters  with  the 
tetter  "A"  cor  responding  to  the  first  line  In  the 
window* 


c  Inverts  the  case  of  all  letters  typed  by  the  user 

(1.e.«  converts  upper-case  to  lower-case  and  vice 
versa).  This  option  will  cause  commands  to  be 
recognized  only  In  upper-case  and  alphabetic  line 
numbers  to  be  displayed  and  recognized  only  In 
lower-case. 


dC<d1r>3  selects  the  placement  of  the  current  line  pointer 
following  a  "d"  (delete)  command.  <d1r>  must  be 
cither  ">"  or  "<".  If  ">"  It  specified,  the 
default  behavior  Is  selected!  the  line  following 
the  deleted  lines  becomes  the  new  current  line. 
If  Is  specified,  the  line  Immediately  preced¬ 

ing  the  delete  lines  becomes  the  new  current 
line.  If  neither  Is  specified,  the  current  value 
of  <d1r>  Is  displayed  In  the  status  line* 

f  selects  r-'-tran  oriented  options.  This  Is 

equivalent  0  specifying  both  the  "c"  and  *tf»" 
(see  uelow)  options. 


lC<loo>]  sets  the  line  number  display  option.  Under 
control  of  this  option.  ’sc*  will  continuously 
llspley  the  value  of  one  o?  three  symbolic  line 
numbers*  <lop>  may  be  any  of  the  following! 


«  display  the  current  line  number 

•*  display  the  number  of  the  top  line  on  the 
screen 


1  display  the  number  of  the  last  line  In  the  buf¬ 
fer 


if  <top>  Is  omitted*  the  line  number  display  Is 
disabled. 


tC<tabs>3  sets  tab  stops  accordln  to  <tab*>.  <tabs> 
consists  of  a  scries  cf  nurbers  Indicating  column 
numbers  In  which  tab  stops  arc  to  be  set*  if  a 
number  Is  preceded  by  a  plus  sign  ("♦")»  It  In¬ 
dicates  that  the  number  Is  an  Increment?  stops  are 
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u[ <chr >  3 


vC< 1nt>  3 


wC< 1nt>  3 


«C  < Inr > 3 


Georgia 


set  at  regular  Intervale  separated  by  that  many 
columns*  beginning  with  the  most  recently 
specified  absolute  column  number*  If  no  such  num¬ 
ber  precedes  the  first  Increment  specification* 
the  stops  are  set  relative  to  column  1.  Ry 
default*  tab  stops  are  set  In  every  thrld  column 
starting  with  column  1*  corresponding  to  a  <tabs> 
specification  of  ".J".  If  <tab*>  1$  omitted*  the 
current  tab  soar, Ina  Is  displayed  In  the  status 
line. 

selects  the  character  that  *  se*  displays  In  place 
of  unprintable  characters.  <chr>  may  be  any 
printable  character*  It  Is  Initially  set  to 
blank.  If  <chr>  Is  omitted*  *se»  displays  the 
current  replacement  character  on  the  status  line 
at  the  bottom  of  the  screen. 

sets  the  default  “overlay  column*.  This  Is  the 
column  at  which  the  cursor  Is  Initially  positioned 
by  the  "v"  command.  <1nt>  must  he  a  positive 
Integer*  or  a  dollar  sign  ft)  to  Indicate  the  end 
of  the  line.  If  <1nt>  is  omitted*  the  current 
overlay  column  Is  displayed  In  the  status  line. 

sets  the  "warning  threshold"  to  <1nt>  which  must 
be  a  positive  Integer.  Whenever  the  cursor  Is 
positioned  pt  or  beyond  this  column*  the  column 
number  Is  displayed  In  the  status  line  at  the  bot¬ 
tom  of  the  screen  and  the  terminal’s  bell  Is  soun¬ 
ded.  If  <1nt>  is  omitted*  the  current  warning 
threshold  Is  displayed  on  the  status  line.  The 
default  warning  threshold  Is  7A »  corresponding  to 
the  first  column  beyond  the  right  edge  of  the 
screen  on  an  PO  column  crt. 

splits  the  screen  at  the  line  specified  by  <lnr> 
which  must  ne  a  simple  line  number  within  the 
current  window.  All  lines  above  <tnr>  remain 
frozen  on  the  screen*  the  line  specified  py  <lnr> 
Is  replaced  by  a  row  of  dashes*  and  the  space 
below  this  row  becomes  the  new  window  on  the 
file.  Further  editing  commands  do  njt  affect  the 
lines  displayed  In  the  top  part  of  the  screen.  If 
<lnr>  Is  omitted*  the  screen  Is  restored  to  Its 
full  size. 
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5.2.3  Qooteoi  tmmitti  lu.  Mllloa  uut  Pjujulc  aailan 


Since  *se*  takes  Its  commands  directly  from  the  terminal.  It 
cannot  be  run  from  a  script  by  using  Subsystem  I/O  redirec¬ 
tion.  and  Subsystem  erase,  kill,  and  escape  conventions  do 
not  exactly  apply.  In  fact.  »se»  has  Its  oyn  set  of  control 
characters  for  editing  and  cursor  motion!  their  meaning  Is 
as  follows: 


ctrl-A 


ctrl-C 


c  trl-D 


ctrl-E 

e  t  r l »F 


ctrl-G 


ct  r l -H 


ctrl-I 


Tooole  Insert  mode.  The  status  of  the  Insertion 
Indicator  Is  Inverted.  Insert  mode,  when  enabled, 
causes  characters  typed  to  be  Inserted  at  the 
current  cursor  position  In  the  line  Instead  of 
overwriting  the  characters  that  were  there 
orevlously.  When  Insert  mode  Is  In  effect. 
"INSERT"  appears  In  the  status  line. 


Insert  blank.  The  characters  at  and  to  the  right 
of  the  current  cursor  oosltlon  are  moved  to  the 
right  one  cotumr,  and  a  blank  Is  Inserted  to  fill 
the  gap. 


Cursor  up.  The  effect  of  this  key  depends  on 
•se*s  current  mode.  When  In  command  mode*  the 
current  line  pointer  Is  moved  to  the  previous  line 
without  affecting  the  contents  of  the  command 
line.  If  the  current  line  pointer  Is  at  line  1. 
the  last  line  In  the  file  becomes  the  new  current 
line.  In  overlay  mode  (viz.  the  "v"  command), 
the  cursor  Is  moved  up  one  line  while  remaining  In 
th*  same  column.  In  append  mode,  this  key  Is  Ig¬ 
nored. 


Tab  left.  The  cursor  Is  moved  to  the  nearest  tab 
stop  to  the  left  of  Its  current  position. 


"Funny"  return.  The  effect  of  this  key  depends  on 
the  editor’s  current  mode.  In  command  mode,  the 
current  command  line  Is  entered  as-ls.  but  Is  not 
erased  upon  completion  of  the  command!  In  append 
mode.  the  current  line  Is  duplicated!  In  overlay 
node  (viz.  the  "v"  command),  the  current  line  Is 
restored  to  its  original  state  and  command  mode  Is 
reentered  (except  If  under  control  of  a  global 
oreflx). 


Cursor  right, 
the  right. 


The  cursor  Is  moved  one  column  to 


Cursor  left.  The  cursor  Is  moved  one  column  _  to 
the  left.  Note  that  this  does  not  erase  any 
characters !  It  simply  moves  the  cursor. 


Tab  right.  The  cursor  Is  moved  to  the  next 
stop  to  the  right  of  Its  current  position. 


tab 
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c  t  r  l  -K  Cursor  down.  As  with  the  ctrl-0  key*  this  key’s 
effect  depends  on  the  current  editing  mode*  In 
command  mode*  the  current  line  pointer  Is  mowed  to 
the  next  line  without  changing  the  contents  of  the 
command  line#  If  the  current  line  pointer  Is  at 
the  last  line-  In  the  file*  line  1  becomes  the  new 
current  line.  In  overlay  eode  tvlr.  the  "v"  com¬ 
mand)*  the  cursor  Is  moved  down  one  line  while 
remaining  In  the  same  column*  In  append  mode* 
ctrl-X  has  no  effect. 

ctrl-L  Scan  left.  The  cursor  Is  positioned  according  to 
the  character  typed  Immediately  after  the  ctrl-l* 
In  effect*  the  current  line  Is  scanned*  starting 
from  the  current  cursor  position  and  moving  left* 
for  the  first  occurrence  of  this  character,  if 
none  Is  found  before  the  beginning  of  the  line  Is 
reached*  the  scan  resumes  with  the  last  character 
In  the  line.  If  the  line  does  not  contain  the 
’character  being  looked  for*  the  message  "NOT 
FOUND"  Is  printed  In  the  status  line  at  the  bottom 
of  the  screen*  *Se*  remembers  the  last  character 
that  was  scanned  for  using  this  key;  If  the  ctrl-L 
Is  hit  twice  In  a  row*  this  remembered  character 
Is  searched  for  Instead  of  a  literal  ctrl-L* 

ctrl-f*  Newline.  This  key  It  Identical  to  the  NEWLINE  key 
described  below* 

ctrl-N  Insert  newline.  A  newline  character  Is  Inserted 
before  the  current  cursor  position*  and  the  cursor 
Is  moved  one  position  to  the  right.  The  newline 
Is  displayed  according  to  the  current  nonprlntablc 
replacement  character  (see  the  "u"  option). 

ctrl-0  Skip  right*  The  cursor  Is  moved  to  the  first 
position  beyond  the  current  end  of  line* 

ctrl-P  Interrupt.  If  executing  any  command  except  "a"* 
"c"*  "1"  or  "v"*  *se*  aborts  the  command  and 

reenters  command  mode*  The  command  line  Is  not 

erased* 

ctrl-0  Fix  screen*  The  screen  Is  reconstructed  from 

*se»s  Internal  representation  of  the  screen. 

ctrl-R  Erase  right.  The  character  at  the  current  cursor 
oosltlen  Is  erased  and  all  characters  to  Its  right 
are  moved  left  one  position. 

ctrl-S  Scon  right.  This  key  Is  Identical  to  the  ctrl-L 

key  described  above*  except  that  the  scan  proceeds 
to  the  right  from  the  current  cursor  position. 

ctrl-T  Kill  rlqht.  The  character  at  the  current  cursor 
position  and  all  those  to  Its  right  are  erased. 
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ctrl-U  (.rase  left*  The  character  ttf >  tne  left  of  the 
current  cursor  position  Is  deleted  and  all  charac¬ 
ters  t«  Its  rleht  fire  mowed  to  the  left  to  fill 
the  gap*  The  cursor  Is  also  moved  left  one 
column* 


Ctrl -v  Skip  right  and  terminate*  The  cursor  Is  moved  to 
the  current  end  of  lino  and  the  lino  Is 
terminated* 

<trl-W  Ship  left*  The  cursor  Is  positioned  at  column  1* 


ctrl-Y  Kill  left*  All  characters  to  the  left  of  the  cur¬ 
sor  ore  erased!  those  above  and  to  the  right  cf 
the  cursor  arr  moved  to  the  left  to  fill  the 
void.  The  cursor  Is  left  In  column  1* 


ctrl-2  Toggle  case  mgoplng  flag*  The  status  o*  the  case 
napping  Indicator  Is  Inverted!  If  case  eapolng  was 
on*  it  K  turned  eff*  and  vice  versa.  Case  map¬ 
ping*  when  In  effect*  causes  all  upper  case  let¬ 
ters  to  be  converted  to  lower  case*  and  sll  lower 
case  letters  to  he  converted  to  upper  case.'  Note* 
however*  that  #se»  continues  to  recognixt  relative' 
lint*  numbers  In  upper  case  only*  In  contrast  to 
the  cose  maoping  option  (see  the  description  of 
ootlons  above).  When  case  napping  Is  oh*  "CASC" 
appears  In  the  status  line. 


NEjlINC  till  right  and  terminate.  The  characters  at  and 
to  the  right  of  the  current  cursor  position  are 
deleted*  and  the  line  Is  terminated. 

OCl  Kill  ill*  The  entire  line  Is  erased*  along  with; 

any  error  messaqe  that  appears  In  the  status  tine. 

CSC  Tscaoe*  The  CSC  key  provides  a  means  for  entering 

»sc*s  control  characters  literally  as  text  Into 
the  file*  In  *acl«  any  character  that  can  be 
'  generated  fro*  the  keyboard  Is  taken  literally 

nhen  It  Immediately  follows  the  CSC  key*  If  the 
character  Is  unprintable  <as  are  all  of  *sc*s 
control  characters)*  It  will  appear  on  the  screen 
according  the  current  nonorlntable  reolacement 
character  (normally  a  blank)* 

Th»-  set  of  control  characters  defined  above  can  l*e  used  for 
correcting  mistakes  while  typing  regular  editing  commanor  * 
for  correcting  commands  that  have  caused  an  error  message  to 
be  dlsolayed*  for  correcting  lines  typed  In  append  mode*  or 
for  Inline  editing  using  the  "v*  command  descried  below* 
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5. 2. a  lit*  catling  lnitcactUUan 

There  arc  a  few  differences  In  command  Interpretation 
between  the  regular  editor  and  the  ♦sc**  The  only  effect  of 
th*  "p"  command  In  *se*  Is  to  position  the  window  so  that  as 
so n/  si  possible  of  the  "printer*  lines  are  displayed  while 
Including  the  last  line  In  the  ranqe.  In  fact*  the  window 
Is  always  positioned  so  that  the  current  line  Is  displayed. 
Typing  a  "oa  command  with  no  line  numbers  positions  the  win¬ 
dow  so  that  the  line  previously  at  the  top  of  the  window  Is 
at  the  bottom.  Inis  can  be  used  to  "page"  backwards  throuoh 
the  file.  I  he  "t"  command*  (which  In  the  regular  editor 
prints  about  a  screenfull  of  text  starting  with  a  specified 
line)*  positions  the  window  so  It  begins  at  the  specified 
line*  and  leaves  the  current  line  pointer  at  this  line. 
Thus*  a  *t"  can  be  used  to  page  forward  throuoh  the  file. 

The  "overlay"  <y>  command  In  the  reqular  editor  *ed*  only 
allows  the  user  to  add  onto  the  end  of  lines*  ana  can  be 
terminated  before  the  stated  range  of  lines  has  been  proces¬ 
sed  by  entering  a  period  by  Itself*  as  In  the  "append"  com¬ 
mand.  Hut  In  *te*«  this  command  allows  arbitrary  chanqes  to 
be  made  to  the  lines*  and  the  period  has  no  special 
meaning.  To  abort  before  all  the  lines  In  the  range  have 
ceen  covered*  use  the  "f unny  return"  character  (ctrl-F). 
Colno  this  restores  the  line  containing  the  cursor  to  the 
state  It  was  In  before  the  "v"  command  was  started. 

•  Sc  •  has  extended  line  number  syntax.  In  general*  whatever 
appears  In  the  left  margin  on  the  screen  Is  an  acceptable 
line  number  and  refers  to  the  line  displayed  In  that  row  on 
the  screen. 
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6.1.1 


•Fat*  4s  a  program  designed  to  facilitate  the  preparation  of 
neatly  formatted  text.  It  provide*  many  feature*,  such  as 
automatic  nargln  alignment.  paragraph  Indentation,  hyphena¬ 
tion  and  pagination.  that  are  designed  to  greatly  ease-  an 
otherwise  tedious  Job. 

It  Is  the  Intent  of  the  next  few  sections  to  familiarize  the 
user  with  the  principles  of  autowatlc  text  formatting  In 
general  and  with  the  capabilities  and  usage  of  *f!»t*  In 
part Icular. 


6*1.2 

• Fn  t  *  takes  as  Input  a  file  containing  text  with  formatting 
Instructions.  It  Is  Invoked  by  a  command  with  various  op¬ 
tional  parameters.  discussed  below.  The  resultant  output  Is 
appropriately  formntted  text  suitable  for  a  printer  having 
backspaclno  capabilities.  The  output  of  *f«t*  1*  mode 

available  on  Its  first  standard  output  port,  and  so  may  be 
placed  In  a  file,  sent  to  a  tine  printer,  or  changed  In  any 
of  n  number  of  ways,  simply  ny  applying  standard  Software 
Toots  Subsystem  I/O  redirection. 

when  * f a t *  Is  Invoked  from  the  Subsystem,  there  are  several 
optional  parameters  that  may  be  specified  to  control  Its 
ooeratlon.  The  full  command  line  syntax  Is 

fot  C  — »  1C  -p<f 1 rs t >t -< l as t > 3  3  {  <f1le  name?  } 

A  brief  explanation  of  the  cryptic  notation:  the  Items 

enclosed  within  souare  brackets  1"C3")  are  optional  --  they 
may  or  cay  not  oe  specified*  Items  enclosed  between  braces 
may  occur  any  number  of  times.  Including  zero*  Items 
enclosed  In  angle  brackets  ("<>")  designate  character 
strings  whose  significance  Is  suggested  by  the  text  within 
the  brackets?  everything  else  should  be  taken  literally. 
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And  now  for  an  explanation  of  what  these  parameters  meant 

-s  If  this  option  Is  selectee*  Mint*  will  pause  at 

the  top  of  each  page*  ring  the  oell  or  burzer  on 
your  terminal*  and  wait  for  a  response*  This 
feature  Is  for  the  benefit  of  people  using  hard* 
cooy  terminals  with  paper  not  having  pin-feed  mar¬ 
lins*  The  correct  response*  to  oe  entered  after 
the  paper  Is  mounted*  Is  a  control-c  (hold  the 
•control*  key  down  and  type  *e*). 

-p  •••  This  option  allows  selection  of  which  pages  of  the 
formatted  document  will  actually  be  printed*  Im¬ 
mediately  following  the  "-p*»  without  ary  Inter¬ 
vening  spaces*  should  be  a  number  Indicating  the 
first  page  to  be  printed*  Followlno  this*  a 
second  number  may  pe  specified*  separated  from  the 
first  by  a  single  dash*  which  Indicates  the  last 
oage  to  be  printed*  If  this  second  numoer  Is 
omitted*  all  remaining  pages  will  oe  produced* 

<f1le>  Any  number  of  file  names  may  be  specified  on  the 
command  line*  #F»t*  will  open  the  files  In  turn* 
formatting  the  contents  of  each  one  as  If  they 
constituted  one  big  file*  When  the  last  named 
file  Is  processed*  »fmt*  terminates*  If  no  file 
names  are  specified*  standard  Input  number  one  Is 
usedv  In  addition*  standard  Input  may  be 
soeclfled  explicitly  on  the  command  line  by  using 
a  dash  as  a  file  name* 


t*i*3  sainafli  tan 


•  P  m  t  * «  like  almost  every  other  text  formatter  ever  written* 
operates  on  an  Input  stream  that  consists  of  a  mixture  of 
text  and  formatting  commands*  Fach  command  starts  at  the 
beginning  of  a  line  with  a  ’control  character**  usually  o 
period*  followed  by  a  two  character  name*  In  turn  followed 
by  some  optional  ’parameters**  There  must  not  t?e  anything 
etse  on  the  Urj*.  For  example*  In 


•ta  H  21  31  Al 


the  control  character  Is  a  oerlc.'d*  the  command  name  is  ta* 
anti  there  are  four  parameters?  "11"*  "21"*  "SI"  and  **1". 
Notice  that  the  command  name  and  all  the  parameters  must  be 
separated  from  each  other  by  one  or  more  blanks*  Anything 
not  recognizable  as  a  command  Is  treated  as  text. 
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4.2.  gums  m  nmiu  hmimni 


4.2.1  f Uitd  Ieil 

•F*t  •  collect*  as  many  words  as  will  fit  on  a  single  output 
line  before  actually  writing  It  out*  regardless  of  line 
boundaries  In  Its  Input  stream*  This  Is  called  •filling* 
and  Is  standard  practice  for  *fmt*.  It  can*  however*  be 
turned  off  with  the  •no-fill*  command 

•  rtf 

and  lines  thenceforth  will  be  copied  from  Input  to  output 
unaltered*  When  you  want  to  turn  filling  back  on  aqatn*  you 
may  co  so  with  the  *f1ll*  command 

•  fl 

and  ♦fnt*  will  resume  Its  normal  behavior* 

If  there  Is  a  partially  filled  line  that  has  not  yet  been 
written  out  when  on  nf  command  Is  encountered*  the  line  Is 
forced  out  before  any  other  action  Is  taken*  This 
phenomenon  of  forcing  out  a  partially  filled  line  Is  known 
ns  a  ’break*  and  occurs  Implicitly  with  many  formatting  com¬ 
mands*  To  cause  one  explicitly*  the  ’break*  command 


•  br 

1*  available. 


4*2*2  qyphtQatlQP 

If*  while  filling  an  output  line*  It  Is  discovered  that  the 
next  word  will  not  fit*  an  attempt  Is  node  to  hyphenate  It* 
Although  *f«t*  Is  usually  quite  good  In  Its  choice  of  where 
to  split  a  word*  It  occasionally  mokes  a  gaffe  or  two*  gtv- 
1  no  reason  to  want  to  turn  the  feature  off*  Automatic 
hyphenation  can  be  disabled  with  the  ’no-hyphenation*  com¬ 
mand 


•  nh 

long  enough  for  a  troublesome  word  to  be  processed*  and  then 
reenabled  with  the  ’hyphenate*  command 

*hy 

^cither  co rmand  causes  a  break. 


Georola  Institute  of  Technology 


COBOL  Workbench 


Appendix  6 


FORMATTER 


Pape  225 


6.2.3  SALlifl  Adlu^taeQt 

After  filling  an  output  line*  ’fist*  Inserts  extra  blanks 
between  words  so  that  the  last  word  on  the  line  Is  flush 
with  the  right  margin*  giving  the  text  a  * pro f ess  1 ona l "  an* 
pearance.  This  Is  one  of  several  margin  adjustment  nodes 
that  can  be  selected  with  the  ’adjust*  command 

•ad  <aode> 

The  optional  parameter  <mooe>  may  be  any  one  of  four  single 
characters:  "»"•  •c“*  Hl"  or  "r".  If  the  parameter  Is  "b" 

or  missing*  normal  behavior  will  prevail  —  both  margins 
will  be  made  even  by  Inserting  extra  blanks  between  words. 
This  Is  the  default  margin  adjustment  mode.  If  "c*  Is 
specified,  lines  will  be  shifted  to  the  right  so  that  they 
are  centered  between  the  left  and  right  margins.  If  the 
parameter  Is  "l"*  no  adjustment  will  be  performed*  the  line 
will  start  at  the  left  margin  and  the  right  margin  will  oe 
ragged.  If  "r*  Is  specified*  llnc-s  wllv  be  moved  to  the 
rloht  so  that  the  right  margin  Is  even*  leaving  the  left 
margin  raqqec. 

The  ’no-adjustment •  command 


has  exactly  the  same  effect  as  the  following  ’adjust*  com¬ 
mand  : 


No  adjustment  will  be  performed*  leaving  the  left  margin 
even  and  the  right  margin  ragged.  Tn  no  case  does  a  change 
In  the  adjustment  mode  cause  a  break. 


cmtdlaa 

Input  lines  may  be  centered*  without  filling*  with  the  help 
of  the  ’center*  command 

.  Ct  H 

The  optional  parameter  N  Is  the  number  of  subsequent  Input 
lines  to  be  centered  between  the  left  and  right  margins.  If 
the  parameter  Is  omitted*  only  the  next  line  of  Input  text 
Is  centered.  Typically*  one  would  specify  a  large  number* 
say  1000*  to  avoid  having  to  count  llnest  then*  immediately 
following  the  lines  to  be  centered*  give  a  ’center*  command 
with  a  parameter  of  zero*  For  example! 
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•  ce  1000 
more  lines 
than  !  care 
to  count 

•  ce  o 

It  is  worth  noting  the  di  f  f erence  between 

•  ce 

and 

•  ad  c 

when  the  forner  is  used*  an  Implicit  break  occurs  before 
each  line  is  printed*  preventing  filling  of  the  centered 
lines*  when  the  latter  is  used*  each  line  is  filled  with  as 
many  words  as  possible  before  centering  takes  place* 

6.2.5  sunn:*  i  Ellllna  ml  amain  Aliiaiiini 


Set  margin  adjust¬ 
ment  mode* 

Force  a  break. 

Center  N  Input  text 
lines. 

Turn  on  fill  mode* 

Turn  on  automatic 
hyphenat ion. 


Command 

Syntax 

Initial 

Value 

If  no 

Parameter 

Cause 

Break 

•  od  c 

both 

both 

no 

•  br 

wm 

w* 

yes 

•  ce  * 1 

N=0 

N=1 

yes 

,11 

on 

- 

no 

•  hy 

on 

- 

no 

•  na 

- 

- 

no 

•  nf 

- 

-- 

yes 

•  nh 

- 

m 

no 

•  sb 

off 

m 

no 

•  *b 

on 

- 

no 

Georgia 

Institute  of 
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Turn  off  margin  ad- 
) ustment • 
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6.3.  SfAtiSUi  m  WL  K 


6.3.1  L^Qt  SfiltlDfl 

♦Fmt*  usually  produces  single-spaced  output,  but  this  can  be 
changed,  without  »  break.  uslnq  the  •  llne-spac  1na»  command 

•  It  N 

The  parameter  N  specifies  how  many  lines  on  the  paqe  a  sing¬ 
le  line  of  text  will  use!  for  douole  spacing.  U  would  be 
two.  If  S  Is  omitted,  the  default  (single)  spacing  Is 
reinstated. 

Blank  lines  may  be  produced  with  the  ’space*  command 

•  tp  N 

The  parameter  ?»’  Is  the  number  of  blank  lines  to  produce.  If 
omitted,  a  value  of  one  Is  assumed.  The  tp  command  causes  a 
break!  If  the  current  line  spaclno  Is  more  than  one.  the 
oreak  will  cause  blank  lines  to  be  output.  Then  the  blank 
lines  generated  by  tp  are  output.  Thus.  If  output  Is  being 
double-spaced  and  the  command 

•  tp  3 

Is  given,  four  blank  lines  will  be  generated.  If  the  value 
of  ?J  calls  for  more  blank  lines  than  there  are  remaining  on 
the  current  page.  any  extra  ones  are  d 1 scarded.  This 
ensures  that,  normally.  each  paqe  begins  at  the  same 
distance  from  the  top  ot  the  paper. 


6.3.2  Page  Dlvltjpn 


•Fet  *  automatically  divides  Its  output  Into  pages,  leaving 
adequate  room  at  the  too  and  bottom  of  each  page  for  running 
headings  and  footlnos.  There  ore  several  commands  that 
facilitate  the  control  of  page  divisions  when  the  normal 
behavior  Is  Inadequate. 


The  *begtn-oagc*  command 


•  bp 

causes  a  break  and  a  skip  to  the  top  of  the  next  page.  If  a 
parameter  Is  given.  It  serves  to  alter  the  page  number  and 
so  It  must  be  numeric  with  an  optional  ptus  or  minus  sign. 
If  the  parameter  Is  omitted,  the  page  number  Is  Incremented 
by  one.  If  the  command  occurs  at  the  top  of  a  page  before 
any  text  has  been  printed  on  It.  the  command  Is  Ignored,  ex¬ 
cept  perhaos  to  set  the  page  number.  This  Is  to  prevent  the 
random  occurrence  of  blank  pages. 
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The*  optionally  signed  numeric  parameter  Is  a  form  of 
parameter  used  by  many  formattlna  commands,  when  the  sign 
Is  o*1tted«  It  Indicates  an  absolute  value  to  be  usedt  when 
the  sign  Is  present*  It  Indicates  an  amount  to  be  added  to 
or  subtracted  from  the  current  value* 

The  oage  number  may  be  set  Independently  of  the  *bcg1n-oage# 
command  with  the  ’page-number *  command 

«pn  *N 

The  next  page  after  the  current  one*  when  and  If  It  occurs* 
will  be  numbered  *N.  No  break  Is  caused. 

The  length  of  each  page  produced  by  *fmt»  Is  normally  66 
lines.  This  Is  standard  for  eleven  Inch  oaoer  printed  at 
six  lines  per  Inch.  However*  If  non-standard  paper  Is  used* 
the  printed  length  of  the  pane  may  easily  be  changed  with 
the  •  paae- 1 eno t h •  command 

•  Pi  ±N 

which  will  set  the  lenoth  of  the  page  to  ♦*»  lines  without 
causing  a  oreak. 

Finally*  I4  It  Is  necessary  to  be  sure  of  having  enough  room 
on  a  page*  tay  for  a  figure  or  a  graph*  use  the  ’need*  com¬ 
mand 

•  ne  *■’ 

•Fnt  *  vltl  cause  a  break*  check  If  there  are  N  lines  left  on 
the  current  page  and*  If  so*  will  do  nothing  more.  Other¬ 
wise*  It  will  skip  to  the  top  of  the  next  page  where  there 
should  be  adequate  room. 


6*3*3  iKflsaaifits  flail 

*No-spacef  *ode  Is  a  feature  that  assists  In  preventing  un¬ 
wanted  blink  lines  from  appearing*  usually  at  the  top  of  a 
pane.  .hen  In  effect*  certain  commands  that  cause  blank 
lines  to  be  generated*  such  as  bp*  ne  and  «p*  arc  suppres¬ 
sed.  For  the  most  part*  •no-scscc*  mode  Is  managed 
automat  leal ly*  1i  Is  turned  on  automatically  at  the  top  of 
each  paoe  before  f^e  first  text  has  appeared*  and  turned  off 
again  automatically  when  the  first  line  on  the  page  Is  writ¬ 
ten.  This  accounts  for  the  suppression  of  bp  commands  at 
the  ton  of  a  oaye  and  the  discarding  of  excess  blank  i1r.f>" 
In  so  commands. 
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•Mo-space*  node  may  be  turned  on  explicitly  with  the  ‘no- 
space*  command 


•  nt 


ano  turned  oft  explicitly  with  the  ‘restore-spacing*  command 


| 


•  r* 


Neither  command  causes  a  break. 


^•3.4  iuuuxx  r  Saitlofl  *n£  £m  Capital 


Command 

Syntax 

Initial 

Value 

If  no 
Parameter 

Cause 

Break 

Explanation 

•  bo 

H=1 

next 

yes 

Begin  a  new  Daoe. 

.is  N 

Uz  l 

«sl 

yes 

Set  line  spacing. 

•  n  c  N 

- 

h=l 

y  »'S 

Express  a  need  for  t* 
contlquous  lines. 

•  ns 

on 

- 

no 

Turn  on  *no-space* 
node. 

•  pi  * N 

tl 

CT* 

o* 

*4 

II 

no 

Set  page  length. 

•  pn  *N 

N*1 

Ignored 

no 

Set  page  number. 

•  rs 

- 

- 

no 

Turn  off  ‘no-space* 
node. 

•  so  N 

- 

N=1 

ye* 

Put  out  N  blank 

lines. 


6.4.  amiss  m  momma 


6*4.1 

All  fornattinq  operations  are  performed  within  the  framework 
of  a  page  whose  size  Is  defined  by  four  margins?  too*  bot¬ 
tom.  let*  end  right.  The  top  and  bottom  margins  determine 
the  number  of  lines  that  are  left  blank  at  the  top  and  bot¬ 
tom  of  each  page.  likewise,  the  left  and  right  sa.rglns 
determine  the  first  and  last  columns  across  the  page  Into 
which  text  nay  be  placed. 
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6«*«2  120.  £04  SflUfll  Bagfljna 

Both  the  top  and  the  bottom  margins  consist  of  two  sub¬ 
margins  that  fix  the  location  of  the  header  and  footer 
lines*  For  the  sake  of  clarity*  the  first  and  second  sub- 
maralns  of  the  top  margin  will  be  referred  to  os  ’margin  1* 
and  *aarg1n  2**  and  the  first  and  second  sub-margins  of  the 
Bottom  margin*  *marg  In  3*  and  •margin  A*. 

The  value  of  margin  1  Is  the  number  of  lines  to  skip  at  the 
top  of  each  cage  before  the  neader  line*  plus  one*  Thus* 
marciln  I  Includes  the  header  line  and  all  the  hlank  lines 
preceding  It  from  the  top  of  the  paper.  By  default*  Its 
value  Is  three*  vargln  2  Is  the  number  of  blank  lines  that 
are  to  appear  Between  the  header  line  and  the  first  text  on 
the  page*  Normally*  It  has  a  value  of  two*  The  two 
together  form  a  standard  top  margin  of  five  lines*  with  the 
header  line  rloht  In  the  mlddte.  It  Is  easy  enough  to 
change  these  defaults  If  they  prove  unsatisfactory*  Just  use 
the  *marg1n-l»  and  *»arg1n-2#  commands 

•  ml  ♦  N 

•  m2  *:i 

to  set  either  or  both  sub-margins  to  *U, 

The  bottom  margin  Is  completely  analogous  to  the  top  margin* 
with  margin  5  belnq  the  number  of  blank  lines  between  the 
last  text  on  a  page  and  the  footer  line*  and  margin  «  being 
the  number  of  lines  from  the  footer  to  the  bottom  of  the 
paper  (Including  the  footer).  They  may  be  set  using  the 
•aargln-3*  and  ♦aurqln-a*  commands 

•  m3  *U 

•  a*  *.V 

which  work  Just  like  their  counterparts  In  the  top  margin? 
none  cause  a  break* 


*•*•3  UjlU  tad  Slam  Busin  i 

The  loft  and  right  margins  define  the  first  and  last  columns 
Into  which  text  may  be  printed*  They  affect  such  things  as 
adju'.t-ent  and  centering*  The  left  margin  Is  normally  set 
at  column  one*  thouah  this  Is  easily  changed  with  the  Heft- 
maroln*  command 

•  la  *N 

The  right  margin*  which  Is  normally  positioned  Iri  column 
sixty*  can  be  set  similarly  with  the  •right-margin*  command 

•  rm  ♦  *l 

To  ensure  that  the  new  margins  apply  only  to  suoarquent 
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text*  each  vo«mand  cause*  a  break  before  changing  the  margin 
value* 


4*4.4  Indentation 

It  Is  often  desirable  to  change  the  effective  value  of  the 
left  margin  for  Indentation*  without  actually  cnanalng  the 
marcln  Itself*  For  Instance*  all  of  the  examples  In  this 
guide  are  Indented  from  the  left  margin  In  order  to  set  then 
apart  from  the  rest  of  the  text*  Indentation  Is  easily 
arranged  using  the  ’Indent’  command* 

•  In  ♦  N 


f 

4 

& 


*  ii 


> 


} 


i 


* 


i 

* 

i 


whose  parameter  specifies  the  number  of  columns  to  indent 
from  the  left  margin*  The  Initial  Indentation  value*  and 
the  one  assumed  If  no  parameter  Is  given*  Is  zero  (1*c* 
start  In  the  left  margin). 

For  the  purpose  of  margin  adjustment*  the  current  Indenta¬ 
tion  value  Is  added  to  the  left  margin  value  to  obtain  the 
effective  left  marqln*  In  this  respect*  the  la  and  In  con* 
mands  are  quite  similar*  But*  whereas  the  left  margin  value 
affects  the  placement  of  centered  lines  produced  by  the  ce 
command*  Indentation  Is  completely  Ignored  when  lines  are 
centered. 

Paragraph  Indentation  poses  o  sticky  oroblem  In  that  the  in¬ 
dentation  must  be  applied  only  to  the  first  line  of  the 
paragraph*  and  then  normal  marqlns  must  be  resumed*  This 
can’t  be  done  conveniently  with  the  ’Indent*  command*  since 
It  causes  a  break.  Therefore*  *fmt*  has  a  ’temporary- 
indent’  command 

•  tl  if. 

whose  function  Is  to  cause  a  break*  alter  the  current  In¬ 
dentation  value  by  until  the  next  line  of  text  Is 
produced*  and  then  reset  the  Indentation  to  Its  previous 
value*  So  to  begin  a  new  paragraph  with  a  five  column  In¬ 
dentation*  one  would  say 

•  tl  »5 


6*4.5  £lJH  fllllfcl 

As  If  control  over  the  left  margin  position  and  Indentation 
were  not  enough*  there  1*  yet  a  third  means  for  controlling 
the  position  of  text  on  the  page.  The  concept  of  a  pace  of¬ 
fset  Involves  nothing  more  than  prepending  a  number  of 
thanks  to  each  and  every  line  of  output*  It  is  primarily 
Intended  to  allow  output  to  be  easily  posltioneo  on  the 
paper  w^hout  having  to  adjust  margins  and  Indentation  iwltb 
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all  their 

attendant  side  effects) 

and 

without  having 

to 

physically 

move  the  paper.  Although 

the 

page  offset 

is 

initially  zero,  other  arrangpments 
* cage »o f f set '  command 

may 

be  made  with 

the 

•  po  *N 

which  causes  a  break* 


smitci  z  flicalai  nut  lnfltolillftp 


Command 

Syntax 

Initial 

Value 

1  f  no 

Parameter 

Ceute 

Break 

Explanation 

•  in  ♦  *J 

Ns  0 

N  =  0 

yes 

Indent  left 

margin* 

•  l  a  ♦  N 

N=  1 

K'=l 

yes 

Set  left  icargin* 

.ml  *ii 

N=3 

fi=  3 

no 

Set  too 

margin 

before  and  Including 
page  headino* 


X 

It 

N  =  2 

no 

Set  top  margin  after 

page  heading* 

•  m3  *N 

U-2 

'1  =  2 

no 

Set  bottom  margin 

before  page  footing. 

•  ♦  N 

N=3 

'l=  3 

no 

Set  bottom  margin 

including  and  after 
page  footing* 


po  .N 

af 

II 

O 

N  =  0 

yes 

Set  page  offset* 

rt  ♦  %’ 

U  =  f>0 

N  -  60 

yes 

Set  right  margin* 

ti  **i 

N  =  0 

N  =  Q 

yes 

Temporarily  indent 

left  margin* 


6*5.  HtAflittfiS*  m  UIUS 


6«5.i  inm  zah  nun 

A  three  part  title  is  a  line  of  output  consisting  of  three 
scg ‘tents*  The  first  segment  is  left-justified*  the  second 
is  cent  err  d  between  the  left  and  right  margins,  and  the 
third  is  r i gh t- J us t 1 f led •  For  example 

left  oart  center  part  right  part 
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Is  (<  three  part  title  whose  first  seyaent  Is  "left  part"* 
whose  second  segment  Is  "center  part"*  and  whose  third  sec- 
rat*  r.l  Is  "rtaht  port"* 

To  generate  »  title  at  the  current  position  on  the  page*  the 
•title*  command  Is  available: 

*tt  /left  part/center  part/right  part/ 

In  fact*  this  command  was  useo  to  generate  the  previous 
example.  The  parameter  to  the  title  command  Is  made  up  of 
the  text  of  the  three  parts*  with  each  segment  enclosed 
within  a  oalr  of  delimiter  characters.  Here*  the  delimiter 
Is  a  slash*  but  any  other  character  con  he  used  as  Iona  os 
It  Is  used  consistently  within  the  same  command.  If  one  or 
more  segments  ore  to  be  oaltted*  Indicate  this  with  two  ad¬ 
jacent  delimiters  at  the  desired  position.  Thus* 

•  tl  ///P.ioe  1/ 

specifies  only  the  third  segment  and  would  nroduce  something 
lUe  this: 


Pane  l 

It  1»  not  necessary  to  Include  the  trailing  delimiter*. 

To  facilitate  cage  numbering*  you  may  Include  the  sharp 
character  ("*">  anywhere  In  the  text  of  the  title*  when  the 
command  Is  actually  performed*  ’frit*  will  replace  all  oc¬ 
currences  of  the  "9"  with  the  current  rage  number.  To 
produce  a  literal  sharp  character  In  the  heading*  It  should 
be  preceded  by  an  "3" 


so  that  It  loses  Us  special  meaning. 

The  Mrst  segment  of  a  title  always  starts  at  the  left  mar¬ 
gin  as  specified  by  the  l*  command.  While  the  third  segment 
normally  **nds  at  the  right  margin  as  specified  by  the  rm 
command  *  tnls  can  be  changed  with  the  • length-of-t 1 1 le  *  com¬ 
mand  : 


•  It  JH 

which  changes  the  length  of  subsequence  titles  to  *tif  still 
Beginning  at  the  left  margin.  Note  that  the  title  length  Is 
automat  leal ly  set  by  the  and  r»  commands  to  coincide  with 
the  distance  between  the  left  and  right  margins. 
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6.5.2  Pm  audinai  1&4  fafllloai 

The  most  common  uses  for  three  part  titles  are  page  headings 
.mo  footings.  The  header  and  footer  lines  are  Initially 
blank,  Flthcr  one  or  both  may  he  set  at  any  time,  without  a 
break*  ny  uslna  the  ’header*  command 

•he  / lef t /cent er /r Ight / 

to  set  the  oaqe  heading,  and  the  ’footer*  command 
•fo  /left/c enter/rl oh t/ 

to  set  the  laflc  footing.  The  change  will  become  manifest 
the  ne*t  time  the  too  or  the  bottom  of  a  page  Is  reached. 
As  with  the  tl  command,  the  may  be  used  to  access  the 

current  paye  number.  is  an  1 1 lus t r a 1 1  on .  the  following  con- 
manes  were  usoo  to  generate  the  page  headings  ana  footlnns 
for  this  o<i  1  ae  ! 

.he  / * r * t •  User’s  Guide/// 

.fo  //-  i  -// 

6*5.3  5UUULX  Z  tltA4iflil&*  tflflliZl  AC*  lilitl 


r 

W  V<w 

sand 

Initial 

If  no 

Cause 

Synt  as 

Value 

Parameter 

Break 

Ciplanat Ion 

•  f  0 

•I’c’r’ 

b  l  ank 

blank 

no 

Set  running 

oage 

f  oot  Inc. . 

•  h» 

♦I’c’r* 

blank 

hi  ank 

no 

Set  running 

page 

heading. 

.11 

*'! 

V=GC 

SSI 

vO 

II 

no 

Set  lenqth 

of 

f 

header.  footer 

and 

titles. 

.tl 

’I’c’r’ 

blank 

Man  k 

yes 

Generate  a 

three 

part  title. 
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h  •  6  •  1  Tflfcl 


Just  like  any  good  typewriter,  Mmt*  has  facilities  for 
tabulation.  When  It  encounters  a  srctlol  char*) cter  in  Its 
Inout  called  the  Mao  character*  (analogous  so  the  7  *  f*  key 
on  <i  t ynewr 1  ter >  •  It  au  t  o<r.«»  t  1  ca  1 1  y  advances  to  thf*  ne*.  out- 
out  column  in  which  a  Mao  stop*  has  peer  pr-viously  set* 
Tat)  stops  arc  always  measured  t  ren  the  £<<££. ii*£  itii 
SiULiliQ’  th»t  Is,  the  left  margin  plus  the  current  Indenta¬ 
tion  or  temporary  Inoentatlon  value*  Whatever  column  the 
left  margin  may  actually  be  In,  It  Is  always  assumed  to  ut 
column  one  for  the  purpose  of  tabulation* 

Origin. illy,  a  tab  stop  Is  set  in  every  eighth  column,  start¬ 
ing  with  column  nine.  Tnis  may  oe  changen  using  the  Mao* 
c  ostatio 


•  ta  < c o l >  <co l >  ••• 

Cach  parameter  specified  rust  he  a  number,  and  causes  a  tab 
stoo  to  oe  set  In  the  corresponding  outfut  column.  All 
existing  stops  are  cleared  before  setting  the  new  ones*  one. 
a  stoo  Is  s**t  In  every  column  beyond  the  last  one  specified* 
This  nejns  that  If  no  col  urns  are  specified*  s  stop  ir  set 
In  every  co lunn . 

Py  default,  *fmt*  recognizes  the  ASCII  TAP,  control-1,  as 
the  • t ab  character*.  Put  since  this  Is  an  Invisible  charac¬ 
ter  and  Is  guaranteed  to  be  Interpreted  differently  by  Dif¬ 
ferent  terminals,  It  can  be  chanqed  to  any  character  with 
the  • t ab-charac t cr •  command: 

•  tc  <c  ha  r > 

'While  there  Is  no  restriction  on  what  oartlcular  character 
Is  specified  for  <char>,  it  Is  wise  to  choose  one  that 
doesn’t  occur  elsewhere  In  the  text*  If  you  omit  the 
parameter,  the  tab  character  reverts  to  the  default* 

w  h  •*  n  •  f  n  t  *  expands  a  tab  character.  It  normally  outs  out 
enough  blanks  to  get  to  the  next  tab  stop*  In  other  words, 
the  default  ’replacement*  character  Is  the  olank.  This  too 
say  easily  be  changed  with  the  • ren l accmen t -charac t er *  cor- 
mand : 


•re  <char> 

As  with  the  tc  command,  <char>  may  be  any  single  character. 
If  omitted,  the  default  Is  used. 

A  common  alternate  replacement  character  is  the  period, 
which  Is  freouentiy  used  In  tables  of  contents.  The  follow¬ 
ing  ex a mole  Illustrates  how  one  might  oe  constructed: 
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.t*  52 
.tC  \ 

Section  Na*e\Page 

•  rc  • 

•  «p 

•  nf 

,ta  53 
#*iastes\l 

r  H  l  Ing  and  Margin  Adjustments? 
Spacing  and  Page  Controls 

•  tp 

.f  1 

Thi  result  shoulo  look  about  like  this: 

lection  Name 
•'Mqe 


<uSlCS..*. 1 

r  1 1 1 1  n  g  and  Margin  Ad Ju* tnent •••••••••••••••• . ••••••  2 

<pac  1n«  and  pooe  font  rol  .5 


(>•<>•2  iMUU£X  Z  XAlUiULUftO 


Command 

Syntm* 

Initial 

Value 

If  no 

Parameter 

Cause 

Break 

Eaplanat Ion 

. t  a  0  ... 

?  17  ... 

all 

no 

Set 

t  ab 

stops. 

•  tc  c 

T  AO 

no 

Cct 

t  a& 

character. 

•  r  c  c 

ila/ik 

HL  ANK 

no 

Set 

tab 

reDlacrment 

character. 


i 

i 

I 


6* 7.  oumma 


6.7.1  CflHSPtH 

It  Is  rare  that  a  flocunent  survives  Its  writing  under  the- 
pen  of  Just  one  author  or  editor.  More  freouently*  sever  , l 
different  people  are  likely  to  put  In  their  two  cents  worth 
concerning  Its  format  or  content.  So*  If  the  author  Is 
particularly  attached  to  something  he  has  written*  he  Is 
well  advises  to  say  so.  Comments  are  an  ideal  vehicle  for 
this  purpose  and  are  easily  Introduced  with  the  ’comment* 
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.  *  < comment  ary  t  <•  x  t  > 

Everything  after  the  •  up  to  and  including  the  next  n«*wl1r<p 
character  is  completely  ignored  Oy  •fmt*. 

6*7.2  eoldf acing  Underlining 

*  F 1 1  *  makes  provisions  for  boldfacing  and  yn^er J^Jn^ ng  lines 
or  parts  thereof  with  two  commands; 

•  bf  •< 


boldfaces  the  next  U  linos  of  input  text*  while 


•  ul  "• 

underlines  the  next  N  lines  of  input  text*  In  both  cases* 
if  \  is  omitted*  a  value  of  one  is  assumed.  Neither  command 
causes  a  break*  atlowino  sinole  woros  or  phrases  to  be  bole- 
faced  or  underlined  without  affectlno  the  rest  of  the  output 
line. 

It  is  also  possible  to  use  the  two  In  come  1 na t i on .  Tor 
instance*  the  section  heading  at  the  beginning  of  this  sec¬ 
tion  was  oroduced  by  a  seauence  of  commands  and  text  similar 
to  the  following; 


•  c* 

•  bf 

•  ul 

v 1  see 1 1 ancous  Conxsnns 

As  with  the  ’center*  ro-^ann*  t  h  "  s  e  two  comma  nos  irr  often 
conveniently  used  to  bracket  the  lines  to  pc  ffectcd.  1c* 
spccifyina  a  huac  parameter  value  with  the  first  occurrence 
of  the  command  and  a  value  of  <rer  o  with  the  second; 

•bf  1000 
•ul  1000 
lots  of  lines 
t  o  be 
boldfaced 
and 

under l ined 

•  bf  0 

•  ul  0 
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6.7*3  £*flUfti  &hAIi&iati 

As  nenHoned  in  the  first  section.  command  tines  are 
d i s t  inou i snort  from  text  ay  the  presence  of  a  ‘control 
character*  in  column  one.  In  atl  the  examples  cited  thus 
far,  i>  period  has  been  used  to  represent  the  control  charac¬ 
ter.  It  is  possible  to  select  any  character  for  this 
purpose.  In  fact*  several  occasions  arose  in  the  writing  of 
this  appendix  which  called  for  use  of  .m  alternate  control 
character.  particularly  in  the  construction  of  the  command 
summaries  at  the  end  of  each  section.  U«e  ‘control- 
character*  come. and  nay  hr  used  anywhere  to  select  a  new 
value! 

•  CC  <ch<,  r> 

Th“  parameter  (chsr>.  which  »ay  he  any  single  character, 
becomes  the  new  control  character.  If  the  oaraeetcr  is 
o  n  1 1  tee.  the  familiar  period  is  reinstated. 

It  h <  s  been  shown  that  Many  commands  automatically  cause  a 
break  before  they  perform  their  function.  -hen  this 
presents  a  nrjblen.  it  can  bo  altered.  If  Instead  of  us i no 
the  basic  control  character  the  *no-break‘  control  character 
is  used  to  introduce  a  command,  the  automatic  break  that 
would  normally  result  is  suppressed.  The  stanoord  no-break 
control  character  is  the  grave  accent  <"**>»  but  nay  casil> 
oe  changed  with  the  following  command 

•  c2  <  c  n a  r > 

As  with  the  cc  command,  the  parameter  may  be  any  single 
character,  or  may  be  omitted  if  the  default  value  is 
desired. 


Ecaiatlna 

bri-'f.  one-line  messages  «ay  be  written  to  the  user’s 
terminal  using  the  ‘prompt*  conmanrt 

•er  Cbrief.  one-line  message? 

Thr  text  that  is  actually  written  to  the  terminal  starts 
with  the  first  non-ol«nk  character  following  the  command 
name,  one  cont inucs  up  to.  but  not  inclufino.  the  next 
newline  character.  If  a  newline  character  should  he 
included  1m  the  messaom,  the  escape  sequence 


o 


may  pe  us 
message  pv 
aoos t  r  ot hr . 
th-n  print  fhe  rest 


W  <  v  »  l 


precedino  the  message 

wilt  discard  this  cna 
of  the  message  verba tin. 


‘rat 


charac  ter.  but  will 
ror  instance. 
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•  er  *  this  Is  a  message  with  “3  leading  blanks 

would  write  the  following  text  on  t ho  terninaU  leaving  the 
cursor  or  carriage  at  the  cna  of  the  messane 

this  is  -i  message  with  'a  leading  blanks 

For  a  mul 1 1  ole- li ne  message*  try 

•er  nul  t  Iple^nl  ineSnraessage-in 

The  output  should  look  like  thist 

multiple 
l  Inc 
message 

Prompts  are  particularly  useful  in  form  letter  applications 
where  there  may  be  several  pieces  of  information  that  'fist* 
has  to  ask  for  in  the  course  of  its  work.  The  next  section 
descrlbrs  how  •  f  nt  *  can  dynamically  obtain  information  from 
the  user. 

6.7.5  EmUitlt  ItftlQlllaO 

If  *f»t*  should  ever  encounter  an  ’exit*  commano 

•  ex 

in  the  course  of  doing  its  Job.  it  will  cause  a  break  and 
exit  Immediately  to  the  Subsystem. 
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6.7.6  iuiuu  -  Blmllioiflyi  Camofli 


Coaaand 

Syntax 

Initial 

Value 

If  no 

Paraaeter 

Cauat 

Braak 

Explanation 

. « 

- 

- 

no 

Introduce  a  comment. 

.of  V 

N  -  C 

6=1 

no 

Foldface  '!  Input 

text  lines. 

•  c  c  C 

♦ 

% 

no 

Set  no-orcak  control 
character. 

. cc  c 

• 

• 

no 

Set  basic  control 

character. 

• C r  text 

- 

Ignored 

no 

•rite  i  message  to 
the  terminal. 

•  e » 

- 

- 

yes 

Exit  Immediately  to 
the  Subsystem. 

.ui  »; 

*»=r- 

U~  1 

no 

Underline  N  Input 

text  lines. 

6.8.  INPUT  PROCESSING 


6*8.1  Incut  £US  Control 

Up  to  this  point.  It  has  brcn  assumed  that  *  f  *n  t  •  rend:,  only 
fro*  Its  standard  Inout  file  or  from  files  specified  as 
oorameters  on  the  cosnanri  line.  It  Is  also  possible  to 
dynamically  Include  the  contents  of  any  file  In  the  midst  of 
formatting  another.  This  aids  oreatly  In  the  modularisation 
of  l a roc*  other.  Isr  unwieldy  documents,  or  In  the  definition 
of  frequently  use)  sec u cnees  of  commands  and  text. 

The  'source*  cote  and  Is  available  to  dynamically  Include  the 
contents  of  a  file: 

.so  <  f  1 1  o  > 

The  oarameter  <f1le>  Is  .mandatory*  It  may  be  on  arbitrary 
file  system  pathname*  or*  as  with  file  names  on  the  common,) 
line*  >  single  dash  to  specify  standaro  input  number 

one . 
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The  effect  of  a  ‘source*  command  is  to  temporarily  preempt 
the  current  input  source  and  benin  reading  from  the  named 
file.  When  tne  eno  of  that  file  Is  reached*  the  original 
source  of  input  is  resumed.  Files  included  with  ‘source* 
commands  may  themselves  contain  other  ‘source*  commands*  in 
fact*  this  ‘nestino*  of  input  files  may  be  carried  out  to 
virtually  -my  depth. 

‘r<Tt‘  provides  one  additional  command  for  manipulating  input 
files.  the  ‘next  file*  command 

•  nx  <  f i  le  > 

may  oe  usea  for  either  one  of  two  purposes.  If  you  soecify 
a  < f i l e >  parameter*  alt  current  input  files  are  closed 
(including  those  opened  with  to  commands)*  and  the  named 
file  becomes  the  nc*  input  source.  You  can  use  this  for 
repeatedly  processing  tne  same  file*  as*  for  example*  with  a 
form  tetter.  If  you  omit  the  < f i le>  parameter*  ♦  f  rnt  •  still 
closes  all  of  its  current  input  files.  Out  instead  of  using 
a  file  name  you  supply  with  the  nx  command*  it  uses  the  next 
file  named  on  the  command  line  that  Invoked  ‘fat*.  If  there 
1$  no  next  file*  then  formatting  terminates  normally. 

Neither  the  so  command  nor  the  nx  command  causes  a  break. 


*•*•2  Em&llaoi  tad  Kicliftlti 

Whenever  ‘fmt*  reads  a  line  of  input*  no  matter  what  the 
source  nay  be*  there  is  a  certain  amount  of  ‘pre-process  ino* 
cone  before  any  other  formatting  operations  take  place* 
This  pre-process ing  consists  of  the  interpret  at  Ion  of  ‘func¬ 
tions*  and  *va r 1 aol cs • •  A  ‘function*  is  a  oredefined  set  cf 
actions  that  produces  a  textual  result*  possibly  basro  on 
some  user  supplied  textual  input.  For  nxemple*  one 
hypothetical  function  might  be  named  *tine**  a no  its  result 
might  be  a  textual  representation  of  the  current  time  of 
da  y : 

0hJ3i:i9  ,■$ 

A  ’variable**  on  the  ot^cr  hand*  is  si-ply  one  of  ‘fmt*s 
internal  parameters*  such  as  the  current  page  length  or  the 
current  line-spaclno  value.  The  result  of  a  variable  is 
Just  a  textual  representation  of  the  value  of  that 
parameter. 

From  the  standpoint  of  a  us«r*  functions  and  variables  are 
very  similar.  In  fact*  they  are  invoked  ioentically  by 
enclosing  the  appropriate  name  in  square  brackets: 

C  t ime  3 
C  Is  3 
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When  •  f  mt  *  sees  such  a  construct  In  an  input  line*  It  ex¬ 
cises  everything  in  between  the  brackets*  including  the 
brackets  themselves*  and  inserts  the  result  of  the  function 
or  variable  In  its  place*  Naturally*  anything  not  recog¬ 
nizable  as  a  variable  or  a  function  is  left  alone*  To  place 
the  strlnq  "ttimel"  in  some  text*  just  type  "  CHme]"?  the 
"S'"  preceding  the  left  bracket  makes  it  lose  its  special 
mean i no • 

The  *numaer  registers*  are  ten  accumlators  on  which  simple 
arithmetic  operations  can  be  performed*  They  exist  in  the 
formatter  specifically  for  the  1  rap  lament  at  1  on  of 
automatically  numbered  sections  and  paragraphs * 

At  {Ms  writing*  functions  and  variables  are  still  evolvinq. 
Tut  the  features  Just  cescrlbed  are  rather  s tab te  and  will 
probably  remain  so  in  future  expansions*  At  this  point*  the 
available  functions  and  variables  are: 

Fund  ions: 

3  a  te 
day 
t  ine 

Variables: 


r  c 

Current 

basic  control  character 

r  Z 

Current 

no-break  control  character 

1  n 

Current 

Indentation  value 

l  m 

Current 

left  maroin  value 

l  n 

Current 

line  number  on  the  page 

l  s 

Current 

line-soacing  value 

ml 

C  u  r  r  c  n  t 

macro  invocation  level 

-  1 

Current 

margin  1  value 

—  t 

Cur rent 

margin  2  value 

-i  x 

Current 

margin  '  value 

-  * 

Current 

margin  *  value 

o  l 

Current 

page  length  value 

on 

Current 

page  number 

00 

Current 

page  offset  value 

rr 

Current 

right  margin  value 

t  c 

Current 

tab  character 

t  i 

Current 

temporary  Indentation  value 

6*8.3  imua£x  r  Jtn&ul  Ecfitmloa 


Command 

Initial 

I  f  no 

Cause 

Syntax 

Value 

Parameter 

Break 

Explanation 

•n*  file 

- 

next  arg 

no 

Move  on  to  the  next 
input  file* 

•so  file 

- 

ionored 

no 

Temporarily  alter 

the  Input  source* 
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6.9.  HACROS 


6.9.1  fujLta  B&llnllAia 

A  iincro  Is  nothing  more  than  a  frequently  used  scout* nee  of 
commands  ano/or  text  that  have  teen  grouped  together  under  a 
single  name.  This  name  nay  then  be  use  a  Just  like  s  r.  or¬ 
dinary  command  to  Invoke  the  whole  group  In  one  fell  swoop. 

Tho  definition  (or  redefinition)  of  a  macro  starts  with  .» 
•define'  command 

•  de  xx 

whose  parameter  Is  a  one  or  two  character  string  that 
oecones  the  name  of  the  macro.  The  macro  name  muy  consist 
of  any  characters  other  than  blanks*  tabs  or  newlines)  upper 
and  lower  case  are  slqnl f leant .  The  definition  of  the  macro 
continues  until  a  matching  *eno*  command 

•  en  xx 

Is  encountered.  Anything  may  appear  within  a  nacro 
definition*  Including  other  macro  definitions.  The  only 
processing  that  Is  done  during  oeflnltlon  Is  the  Interpreta¬ 
tion  of  variables  and  functions  (l.e.  things  surrounded  by 
squire  brockets).  Other  than  this*  lines  are  stored  exactly 
as  they  are  read  from  the  Input  source.  To  Include  a  func¬ 
tion  call  In  the  definition  of  a  macro  so  that  Its 
In? er pret at  Ion  will  be  delayed  until  the  macro  Is  Invoked* 
the  opening  bracket  should  !e  preceded  by  the  escape  charac¬ 
ter  "S".  r0r  example* 

•  »  t m  ---  tin*  of  day 

•  de  tr 
H  time! 

•  en  tm 

would  produce  the  current  time  of  day  when  Invoked*  whereas 

••  tm  - - -  time  of  day 

•  de  t sr 

c  1 1m*  1 

•  en  t * 

would  produce  the  time  at  which  the  macro  definition  was 
processed. 


\  •  « 
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6.9*2  q^trs  inMocf 

Again*  o  macro  Is  invoked  like  an  ordinary  command:  a 
control  character  at  the  .eqinnlnq  of  the  tine  Immediately 
totlowed  by  the  name  of  the  macro*  *^o  to  Invoke  the  above 
*  t  1  me-o  f -da  y  *  macro*  one  might  say 

•  tn 


As  with  ordinary  commands*  macros  may  have  parameters*  In 
fact*  anytMno  typed  on  the  line  after  the  macro  name  Is 
available  to  the  contents  of  the  macro.  As  usual*  blanks 
ano  tabs  serve  to  seoarate  parameters  from  each  other  ana 
fron  the  macro  name.  tf  It  Is  necessary  to  Include  a  blank 
or  a  tab  within  a  parameter*  It  may  be  enclose*;  In  quotes. 
T  hu  *. « 

"parameter  one" 

would  constitute  a  single  parameter  and  would  be  passed  to 
the  macro  <>s 

parameter  one 

To  Include  an  actual  Quotation  mark  within  the  parameter* 
type  two  quotes  Immediately  adjacent  to  each  other.  For 
instance* 

"""quoted  string""" 

would  re  passed  to  the  macro  as  the  single  parameter 
" tiuo t e •*  strlnn" 


Within  the  macro*  parameters  are  accessed  In  a  way  simitar 
to  functions  and  variables:  the  number  of  the  deslrec 

parameter  Is  enclosed  1 «,  square  brockets.  Thus* 

:  l  3 

would  retrieve  the  first  parameter* 
i  2  3 

would  frtch  the  second*  and  so  on.  As  a  special  case*  the 
na».,»  of  the  macro  Itself  may  be  accessed  with 

r  o  3 

Assune  there  Is  a  macro  named  "mx"  defined  as  follows! 
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.«  -ax  ---  macro  example 

•  de  »' 

l*ucro  named  ‘[Oj'i  invoked  with  two  tmumcnts: 
•fl3«  ana  *C23*. 

•  en  r« 


Than*  t  y  0 i n  « 


•mi  "Darin  1"  "oaram  2" 

would  produce  the  same  result  as  typing 

'i.icro  named  's»'i  invoiced  with  two  arguments*, 
•oaraifi  i*  and  ‘param  k*» 


Macros  are  quite  hanoy  for  such  common  operations  us  start- 
ina  a  new  oaraoraph*  or  for  such  tedious  tasks  as  the 
construction  of  tables  like  the  ones  appearing  at  the  end  of 
each  section  in  this  guide.  For  some  examples  of  frequently 
used  macros*  see  the  applications  notes  in  the  following 
pages  * 


6.9.3  Su«%ary 

i  Bitcai 

Command 

Initial 

If  no 

Cause 

Syntax 

Valu* 

Parameter 

Break 

Explanation 

•  dc  xx 

ignored 

no 

Degin  Definition  or 
redefinition  of  a 
macro. 

•  en  xx 

- 

1 snored 

no 

Cno 

definition. 

macro 

6.10.  APPLICATIONS  NO^S 

The  next  few  sections  will  Illustrate  the  capabilities  of 
•fnt*  with  some  actual  appl icat ions.  Most  of  the  examples 
are  macros  that  assist  in  common  formatting  operations*  but 
attention  has  also  oecn  given  to  table  construction,  ill  of 
the  macros  presented  here  are  available  for  general  use  in 
the  file  */'e x t ra/ 1  * ic ro/re por t *  *  which  may  be  named  on  the 
command  line  tnvokino  ’fint*  or  may  be  included  with  a  ♦sour¬ 
ce*  command  as  follows: 

•SO  /extra/fraacro/report 
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6.10.1  EjLtlflEl&frl 

One  standard  way  of  beginning  a  new  paragraph  is  to  skip  a 
line  and  indent  by  a  few  spaces.  This  can  be  done  by  giving 
an  sp  command  followed  oy  a  ti  command.  A  better  way  is  to 
define  a  macro.  This  a Hows  procrastination  on  deciding  the 
fornat  of  paragraphs  and  facilitates  change  at  some  later 
date  without  a  major  editing  effort*' 


Here  is  an  example  of  a  paragraph  macro! 


•i  pp  ---  begin  paragraph 

•  dt  pp 

•  *P 

•  ne  2 

•  1 1  JC  1  n  ] 

•  ti 

•  ns 

•  en  pp 


c1rr.t  a  line  is  skipped  via  the  *space*  command.  Then, 
after  checking  that  there  is  room  on  the  current  page  for 
the  first  two  lines  of  the  new  paragraph*  a  temporary  In¬ 
dentation  is  set  up  that  Is  five  columns  to  the  rioht  of  the 
runninj  indentation  with  the  two  ti  commands,  finally*  no- 
so.«ce  node  is  turned  on  to  l.uppress  unwanted  Blank  lines. 


6.10.2 


Sub-headings  nay  be  easily  produced  with  the  following 
mac  ro! 


. I  sn  ---  suo-headinq 

•  d*  sh 

•  SP  2 

•  ne  * 

•  ti  31  1  n  J 

.bf 

C  13 

•  PP 

•  en  sn 

c  i  r  s  t  »  two  plank  lines  are  put  out.  Then  it  is  determined 
If  there  arc  four  contiguous  lines  on  the  current  page!  one 
for  the  heading  itself*  one  for  the  blank  line  after  the 
heading*  and  two  for  the  first  two  lines  of  the  next 
paragraph.  The  temporary  indentation  value  is  tftor.  set  to 
coincide  w*’h  the  current  indentation  value.  '.ext*  the 
first  oaraseter  passed  to  the  macro  (the  text  of  the  sub¬ 
heading)  Is  boldfaced  and  a  new  paragraph  is  begun.  The 
"no"  tacro  will  Insert  the  blank  line  after  the  heading. 
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6.10.3  QjlfijC  tlSlrfiDfll 

An  example  of  a  macro  to  produce  major  headings  1*.  the  fol- 
towinc! 

• *  «  h  ---  major  headlncj 
»de  nn 

.  sp  3 

•  ne  ‘3 

•  ce 

•  ul 
.bf 
t  1  3 

•  sp 

•  PP 

•  en  mh 

This  Is  simitar  to  the  sub-heading  macro!  three  blank  lines 
are  out  out?  a  check  for  enough  room  is  made*  the  parameter 
is  centered,  underlined  and  boldfaced*  another  blank  tine  is 
put  out?  and  a  net*  paragraph  is  begun. 


6*10.4  Quqtatlops 

Lengthy  Quotations  are  often  set  apart  from  other  text  oy 
atterino  the  left  ano  riqht  mam  Ins  to  narrow  the  width  of 
the  quoted  text.  Hero  is  a  pair  of  macros  that  may  be  used 
to  delimit  the  beginning  and  end  of  a  direct  quotation! 

••  po  ---  oegin  direct  quote 
■  de  bp 

•  SP 

•  ne  1 
.In  *0 
» rm  -b 
.It  >5 

•  an  »q 


•a  oo  ---  end  direct  Quote 

•  dt  co 

«sp 

•  in 

.rm 

•  en  co 

Notice  the  It  command  in  the  first  macro.  To  avoid  affect¬ 
ing  oaqe  headinas  and  fegtlnos*  the  left,  margin  is  not  ad¬ 
justed*  rather,  an  additional  indentation  is  applied.  eut 
to  increase  the  right  margin  width,  there  Is  no  other  alter¬ 
native  but  to  use  the  rm  command.  The  *t Itte-lcngth*  com¬ 
mand  Is  thus  necessary  to  allow  headings  and  foot  Inns  to 
remain  unaffected  by  the  Interim  right  margin. 
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*.10.5  Italic! 

Since  most  printers  can’t  easily  produce  Italic*,  they  are 
frequently  simulated  by  underlining.  The  following  macro 
•Italicizes’  Its  parameter  by  underlining  It. 

••  It  Italicize  tby  underlining) 

•  dt  It 

•  ul 
f  l  ) 

•  en  It 


*•10.*  ftalflltllfll 

V  h  1 1  **  *fnt*  has  built-in  facllltle*  for  boldfacing,  their 
use  may  be  somewhat  cumbersome  If  there  ore  many  short 
obraset  or  slnqle  words  thet  need  boldfaclnat  each  phrase  or 
word  reoulres  two  Inout  llnest  one  for  the  bf  command  and 
one  <cr  the  actual  text.  The  following  macro  cuts  the  over* 
hc.id  In  half  by  allowing  the  commano  ana  the  text  to  appear 
on  the  some  l Ine. 

•a  bo  ---  boldface  parameter 

.dt  bo 

•  bf 

r  \  i 

•  tn  no 


*.10.7  [iitalti 

This  aooendl*  Is  peppered  with  examples,  each  one  set  apart 
from  other  text  by  surrounding  blank  lines  and  additional 
Indentation.  The  next  two  macros,  used  like  thr  "bo"  and 
"eo"  macros,  facilitate  the  production  of  examples. 

•9  bx  ---  begin  example  text 
« de  b « 

•  *P 

•  ne  2 

•  nf 

•In  *10 

•  en  n  x 


.9  ex  ---  end  example  text 

•  de  r  * 

•  sp 
.f  1 

•  In  - 1  0 

•  en  e  * 
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6.10.8  iiut  Cgoilcy&ilfta 

One*  (m»bU‘  o f  table  construction  (for  a  table  of  contents) 
has  already  seen  ixcntlpneo  In  the  section  deal  Inn  with  tabs* 
Another  type  of  table  that  occurs  frequently  Is  that  uscc  In 
the  command  summaries  In  this  appendix..  fach  entry  ot  such 
a  table  consists  of  n  nunocr  of  ‘fields*.  followed  on  the 
right  by  a  body  of  explanatory  text  that  needs  to  be  filled 
and  adjusted. 

The  easiest  way  to  construct  a  table  like  this  Involves  us* 
fnq  a  combination  of  tabs  and  Indentation*  as  the  followlno 
series  of  commands  Illustrates: 

•  In  ♦ * 0 

•  t»  1*  2  A  34  4  1 
.tC  \ 

The  Idea  Is  to  set  a  tab  stop  In  each  column  that  begins  <> 
field*  and  one  last  one  In  the  column  that  Is  to  be  the  left 
*aratn  for  the  r*planatorv  test.  The  e * t r a  Indentation 
moves  the  effective  left  margin  to  this  column.  To  begin  n 
new  entry*  temporarily  undo  the  extra  Indentation  with  a  tl 
command.  and  then  type  the  text  of  the  entry*  separating  the 
fields  fro*  one  another  with  a  tab  character: 

.tl  -40 

field  IVfleld  2\ f  1  e l ri  3\f1eld  4\f xplnnatory  text 

The  first  line  of  the  entry  will  start  ot  the  left  margin. 
Then  all  subsequent  lines  will  be  filled  and  adjusted 
between  column  forty  and  the  right  margin. 


Georgia  Institute  of  Technology  , 


COe£L  Wor)jb?>nch, 


■> ' 

-  ^■a'xc 


Appendi*  6  FORMATTER  25C 
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Command 

Syntax 

Initial 

Value 

If  no 

Parameter 

Cause 

Break 

Explanation 

.  3 

- 

- 

no 

Introduce  a  comment. 

•  ad  C 

hot  h 

both 

no 

Set  margin  adjust¬ 
ment  mode. 

.Of  N 

M  =  C 

Uzl 

no 

Boldface  Input 

text  l 1nes» 

•  ho  *\' 

•<  =  5 

ne  1 1 

yes 

Begin  a  new  page* 

•  or 

- 

- 

yes 

Force  a  break. 

•  Ci1  c 

« 

* 

no 

Set  no-break  control 
chnrac  ter. 

•  c  c  c 

• 

• 

no 

Set  basic  control 

character. 

.  c  e  V 

•J=C 

t.s  1 

yes 

Center  U  1 nput  text 
lines. 

•  dr  »  * 

- 

1 gnored 

no 

Begin  definition  or 
redefinition  of  a 

titc  ro. 

•  en  ii 

- 

1  snored 

no 

Cnd  macro 

definition. 

•  c  r  text 

- 

Ignored 

no 

Write  a  message  to 
the  terminal. 

•  e » 

- 

- 

yr  s 

(alt  Immediately  to 
the  Subsystem. 

.<  1 

on 

- 

no 

Turn  on  fill  node • 

.fo  • l *  c  *  r  • 

blank 

blank 

no 

Set  running  page 

foot  1 n  a • 

.  h  <•  *  1  •  c  •  r  • 

blank 

b  l  ank 

no 

Set  running  page 

heading. 

•  hy 

on 

- 

no 

Turn  on  automatic 

hyphenat Ion. 

•  In  •»; 

'1- 0 

%  =  0 

yes 

Indent  left  margin. 

•  l*  » f 

•|  =  I 

■<=  1 

yes 

Set  left  margin. 
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Command 

Syntax 

Initial 

Value 

If  no 

Parameter 

Cau»e 

Break 

Explanation 

.  1*  n 

N=l 

*.=  l 

no 

Set  line  s p .i c  1  n  ; • 

.It  *n 

fl  =  60 

V  =  60 

no 

Set  lemith  of 
header.  footer  anc 
titles. 

•  ml  *H 

N=  ) 

t.r  l 

no 

Set  t  od  f. •: r  0  1  n 

before  >»nd  including 
p  a  a  e  h  e  a  a  1  n  o  • 

» *2  ±N 

H=2 

'1-2 

no 

Set  top  margin  after 
page  heading. 

•  *  3  ♦  N 

N  =  2 

'1-2 

no 

Set  bottom  m  a  r  c  1  n 

before  page  footlnn. 

.aS 

N=3 

N'=3 

no 

Set  bottom  naroln 
Including  and  after 
pane  footin'). 

•  no 

- 

- 

no 

Turn  off  margin  ad¬ 
justment. 

•  ne  N 

K=1 

yet 

Cxprexs  a  need  for  r. 
contiguous  tines. 

•  n  f 

• 

' 

yet 

T  urn  c  f ♦  fill  node • 
(Also  Inhibits  ad¬ 
justment.) 

.no 

• 

- 

no 

Turn  off  automatic 
hyphenr  1 1  on. 

•  ns 

on 

- 

no 

Turn  on  ’no-space* 
mode. 

•  n»  flic 

- 

next  arp 

no 

Move  on  to  thr  nsxt 
Input  file. 

»ol  *N 

N  =  66 

*•  =  66 

no 

Set  page  length. 

.  pn  *H 

*=1 

1  qnored 

no 

Set  oaoe  number , 

•  po  *N 

M  =  0 

f/  =  0 

yes 

Set  page  offset. 

•  rc  c 

hi  Af«K 

hLANK 

no 

Set  tab  replacement 
character. 

•  r- 

*1  =  60 

N  =  60 

yes 

Set  rlobt  margin. 

•  rs 

- 

- 

no 

Turn  off  *no-sbece* 

mode* 
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Comaand 

Syntax 

Initial 

Valua 

If  no 

Paraaatar 

Cautt 

Brook 

explanation 

.50 

of  f 

- 

no 

Single  blank  after 
end  of  sentence. 

.so  f He 

m 

Ignored 

no 

Temporarily  alter 

the  Input  source. 

*  so  h 

m 

N=  1 

yes 

Put  out  N  blank 

lines. 

.  t  a  ... 

9  17  ... 

all 

no 

Set  tab  stops. 

•  tr  r 

TAP 

TAB 

no 

Set  tab  character. 

.  1 1  ♦  N 

N=0 

N  =  C 

yes 

Temporarily  Indent 

left  margin. 

.tl  * l »f • r  * 

blank 

blank 

yes 

Generate  o  three 

part  title. 

.  u  l  U 

f|s  C 

N=  1 

no 

Underline  N  Input 

text  lines. 

•  *n 

on 

- 

no 

Cxtra  blank  after 

end  of  sentence. 
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6.12.  mmi  at  aanaatias  a&aatu  ax  amaiiaa 

6*i2*i  tlkiliifl  kai  flicaio  AdluilitQl 


Coaaand 

Syntax 

Initial 

Value 

If  no 

Paraaeter 

Cause 

Break 

Explanation 

•  ad  c 

both 

ootb 

no 

Set  rstrgln  adjust¬ 
ment  mode. 

•  br 

- 

- 

yes 

Force  a  break. 

. ce  K 

N=0 

u-l 

yes 

Center  h  Input  tent 
lines. 

.f  1 

on 

- 

no 

Turn  on  fill  none. 

•  My 

on 

- 

no 

Turn  on  automatic 

hyphenation. 

•  no 

- 

- 

no 

Turn  off  maraln  ad¬ 
justment  • 

•  nf 

* 

• 

yes 

Turn  off  fill  mode* 
(Also  Inhibits  ad¬ 
justment  .  ) 

•  nh 

m 

«• 

no 

Turn  off  automat  1 c 
hyphen.it  Ion. 

•  St) 

o'  f 

- 

no 

Single  blank  after 
end  of  sentence. 

•  *0 

on 

• 

no 

Extra  blank  after 

end  of  sentence. 
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Coaaand 

Syntax 

Initial 

Value 

If  no 

Paraaater 

Cauaa 

Brtak 

explanation 

•  OP  *H 

Ms  1 

next 

yes 

Begin  9  new  page. 

•  Is  K 

K=t 

Ms  1 

no 

Set  line  spacing. 

•  nr  t» 

- 

Ns  1 

yes 

express  a  need  for  ff 
conttquou#  lines* 

•  ns 

on 

<* 

no 

Turn  on  •no-space* 
node  • 

•  pi  *N 

-  6  fc 

N  =  66 

no 

Set  page  length. 

•  pn  ♦*. 

?l=  1 

Ignored 

no 

Set  page  number. 

•  rs 

- 

- 

no 

Turn  off  •no-space* 
node  • 

•  S  P  N 

- 

Ms  1 

yes 

Put  out  n  Mank 

lines. 
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6.12.3  Btcflla*  ini  IniiDlillftn 


Command 

Syntax 

Initial 

Value 

If  no 

Parameter 

Cause 

Break 

Explanation 

•  1  n  ♦  N 

N-0 

’J=0 

yes 

Inocnt  left  margin. 

.l»  «N 

N=1 

n=i 

yes 

Set  left  margin. 

.ial  *N 

N  =  3 

Ns  .5 

no 

Set  top  narqfn 
before  ana  including 
oaoeheedlnj. 

•  m2  ♦N 
<»» 

Ns? 

H=2 

no 

Set  top  margin  after 
page  heading. 

•  in  3  *U 

Ns  2 

\«  =  2 

no 

Set  bottom  margin 

before  page  footlna. 

•  ■**  *fi 

M=3 

*!  =  1 

no 

Set  bottom  narpl n 
including  and  after 
poor  foot  Inn. 

•  DO  *  N 

N=0 

Ns  0 

yes 

Set  page  offset. 

.  r»  *N 

NsfiO 

Ns  60 

yes 

Set  rloht  margin. 

.tl  ♦  N 

N  =  G 

Ns  0 

yes 

Temporarily  Indent 

left  a  .r g 1 n . 

6.12.4  Btidioai*  Eaalloai  ana  Iliiti 

Command 

Syntax 

Initial 

Value 

I  f  no 

Parameter 

Cause 

Break 

Explanation 

.fo  • l • c * r * 

blank 

blank 

no 

Set  running  paoe 

foot  Inn.  '  * 

•  ho  ♦ l *c  *  r* 

blank 

blank 

no 

Set  running  paoe  ( 

headino. 

f  l 

.It  *ti 

N:60 

N  =  6  0 

no 

Set  length  of  > 

header*  footer  and  j 

titles. 

.tl  *  l  *  c  *  r  * 

blank 

blank 

ye* 

Generate  a  three 

part  title.  ’> 

} 

t 

* 
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6.12.5  Tabulation 


Coaaand 

Syntax 

Initial 

Value 

If  no 

Paraaeter 

Cause 

Break 

Explanation 

.  t  <1  K  ... 

*  17  ... 

all 

no 

Set 

tab  stops. 

•  t  c  c 

T  A3 

TAB 

no 

Set 

tao  character. 

♦  re  c 

BLANK 

BLANK 

no 

Set 

t  .»b  reo  l  acemen  t 

characltjf  • 


6.12.6  BlntiUOtaMl  tfiMlOJll 


Coaaand 

Syntax 

Initial 

Value 

1  f  no 
Paraaeter 

Cause 

Break 

Explanation 

.* 

- 

- 

no 

Introduce  a  comment. 

.bf  *i 

♦,‘  =  n 

N=1 

no 

Boldface  N  Input 

te*  t  lines. 

.c?  c 

* 

% 

no 

Set  no-break  control 
character. 

.cc  c 

• 

• 

no 

Set  basic  control 

character. 

«er  text 

- 

1 gnor ed 

no 

Write  a  message  to 
the  terminal. 

•  e* 

- 

m 

yes 

r *  1 1  Imredl at cly  t o 
the  Subsystem. 

•  u  l  V 

N~0 

N=1 

no 

Under l Inc  N  Input 

text  lines. 

6*12*7  liuuil  EtSttMioa 

Coaaand 

Syntax 

Initial 

Value 

I  f  no 

Paraaeter 

Cause 

8reax 

Explanation 

.n »  file 

- 

next  org 

no 

Hove  on  to  the  next 
Input  file. 

•  so  file 

• 

1  onored 

no 

Temporarily  alter 

the  Input  source. 
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Coaaand 

Initial 

If  no  Cause 

s 

Syntax 

Value 

Paraaeter  Break 

Explanation 

•  de  xx 

- 

Ignored  no 

Begin  definition  or 
redefinition  of  a 

»ac  ro. 

. cn  xx 

* 

Ignored  no 

Cno  user? 

definition. 
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•Macro*  Is  .in  enhanced  version  of  Kernighan  and  Plauger*s 
macro  preprocessor  from  Chapter  <»  of  Software  tools. 
•Micro*  Is  an  exceedingly  complex  and  powerful  program*  It 
Is  oosslelc  to  use  It  as  a  general  programming  language.  A 
complete  description  of  Its  eaoahlllty  is  beyond  the  scope 
of  this  docunent*  but  a  few  samples  are  presentee  here  to 
help  the  user  sec  one  proficient  in  its  usage. 


i 

j 

| 


5 

\ 


* 

I 


i 


* 

t 

I 


7*i*  m  imt i  of.  a  ntm  fl&EitiinQa 

The  basic  format  of  a  macro  definition  1st 

rtf findoacro-nijnf*  replacement-text) 

"Macro-name*'  is  an  identifier*  i.e.  a  sequence  of  letters 
or  digits  beginning  with  a  tetter.  " Replace no nt-text"  is  a 
(oossKty  empty)  seouence  of  characters*  which  nay  be 
specially  interpreted  by  'nacro*. 

uacro  ornutents  are  referred  to  by  a  construct  of  the  form 
"t<1nteaer>"  in  the  replacement  text.  The  <integer>  must  be 
a  digit  from  C  to  9*  inclusive.  (Digits  1-9  represent  the 
first  through  the  ninth  arguments*  digit  D  represents  the 
ni»»  of  the  macro  itself).  for  example*  the  following  macro 
could  oe  used  to  skip  blanks  ond  taps  In  a  string*  starting 
at  a  given  position: 

def ine( sk iobl* 

while  (SI  (S  2)  ==  BLANK  |  SI  (12)  ==  TAB) 

*2  =  S2  ♦  1 

) 

Here  arc  a  few  examples  of  the  use  of  this  macro: 

sk  5  pb  l  ( l  i ne «  1 ) 
s* iobl  <str «  } ) 

In  order  to  orevent  premature  evoluation  of  a  string*  the 
string  ray  be  surrounded  by  square  brackets.  For  example* 
suppose  we  wishcc  to  redefine  an  identifier.  The  following 
seouence  will  not  work: 

dc  f 1 ne ( x  *  y ) 
dc  f ( no ( < «  z > 

This  is  because  "x"  in  the  second  definition  will  be 
replaced  by  Hy"»  with  the  net  result  of  defining  "y"  tc  be 
The  correct  method  is 
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ae  f  1  no  (  *  *  y  ) 
de  f loe ( C  x  1* 2  ) 

The  square  brackets  prevent  the  premature  evaluation  of  "x"« 


7.2.  BUILT-IN  FUNCTIONS 

♦’iacro*  provides  several  "built-in"  functions*  These  are 

qlven  below; 

divert ( 1 1 1 r name)  or  d  1  ve r t < f 1 1 ename *  append )  or  divert 

"F  Hentime'1  Is  opened  for  output  ana  Its  file  descriptor 
Is  stacked.  whenever  •macro*  produces  output*  It  is 
directed  to  the  named  file.  If  the  second  argument  's 
present*  output  Is  appended  to  the  named  file*  rather 
than  overwriting  It.  If  both  arouments  are  missing* 
the  current  output  file  Is  closed  and  output  reverts  to 
the  last  active  file  (the  one  In  use  when  the  ’divert* 
command  was  recognized). 

dnl  or  <:nl  ( commentary  Information) 

As  suggested  by  Kernlghan  and  Plauger*  *dnl*  may  be 
used  to  delete  all  blanks  and  tabs  up  to  the  next 
newline*  and  the  newline  Itself*  from  the  Input 
stream.  There  Is  no  other  way  to  prevent  the  newline 
after  each  ‘define*  from  being  passed  to  the  output. 
Any  arounents  present  are  Ignored*  thus  allowing  *dnl» 
to  be  used  to  Introcuce  comments. 

1felse(*«b*c«d) 

I*  a  and  b  are  the  same  string*  then  c  Is  the  value  of 
the  expression;  otherwise*  d  Is  the  value  of  the  ex¬ 
pression.  Example;  this  macro  returns  "On"  If  the 
value  of  1  Is  "1"«  "ERh*  otherwise; 

oef1ne(status*1felse(1*ltOK»rRft)> 


Inc lude ( f 1 lename) 

"Filename"  Is  opened  and  Its  file  descriptor  is  stac¬ 
ked.  The  next  time  ’macro*  requests  Input*  It  receives 
Input  from  the  named  file.  When  end-of-flle  Is  seen* 
•macro*  reverts  to  the  last  active  input  file  (the  one 
containing  the  Include)  and  picks  up  where  It  left  off. 

Incr (n) 

Increment  the  value  of  the  Integer  represented  by  n» 
and  return  the  Incremented  value.  For  Instance*  the 
following  pair  of  defines  set  MAXCARD  to  ff)  and  MAXlISC 
to  6 1 : 


def  1ne(.lfixCAAD*B0) 

def  1ne(*AXLINE«  Incr(MAXCARO) ) 
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suost  r  < $«m«n) 

return  a  substring  of  string  s  starting  at  position  m 
with  lenqth  n.  sub 1 1 r < ao c *  1  * 2 )  Is  ab*  subst r ( abc« 2* 1 > 
Is  o«  subs t r (a be* A  * l )  Is  empty.  If  n  Is  omitted*  the 
rest  of  the  string  Is  used:  sub s t r < abc » 2 >  Is  be. 


unde  f ine  <  n  i*c ) 

•Undeflne*  Is  used  to  remove  the  definition  associated 
with  a  name.  Note  that  the  n*ne  should  he  surrounded 
by  brackets*  if  it  is  supplied  as  a  literal*  otherwise 
it  will  :>e  evaluated  before  it  can  oe  undefined.  Exam¬ 
ple: 


undef  ine  <£  sub st r  J > 
undeflne  <Cx3) 
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APPENDIX  8 


1 


I 


THE  PRIHOS  FILE  SYSTEH 


Th»’  PRIf'OS  operating  system  for  the  Prime  400  computer  sup¬ 
ports  is  one  of  Its  services  a  flexible*  hierarchical  file 
system  that  provloes  users  with  the  facility  to  maintain 
large  quantities  of  oata  in  an  orderly*  loqical  manner. 
These  next  few  sections  are  Indended  to  provide  a  brief 
overview  of  the  file  system’s  capabilities  and  features*  If 
Is  somewhat  tutorial  In  nature  and  docs  not  attempt  to  cover 
all  of  the  available  features*  nor  to  present  the  details  of 
Imptementat Ion. 


s.i.  ascmai  aui 

A  file  Is  a  named  collection  of  Information*  preserved  udoo 
some  storage  medium*  such  as  magnetic  disk.  Some  files  may 
contain  text  as  In  an  article  or  a  book*  others  may  contain 
binary  data  oroduced  by  or  to  be  used  as  Inout  to  some 
program*  and  still  others  may  contain  the  actual  executable 
Instructions  of  the  program  Itself.  In  other  words*  no 
oartlculer  structure  is  forced  upon  o  file  by  the  system. 
While  some  programs  may  operate  on  files  with  a  definite 
structure*  it  Is  their  responsibility  to  naintaln  this 
structure  and  of  no  real  concern  to  the  system. 

We  mentioned  above  that  a  file  hat  a  name!  this  raises  the 
auestlon  of  what  arc  the  acceptable  names  for  files.  A 
file  name  consists  of  J.?  or  fewer  characters  chosen  from  the 
Roman  alphabet*  the  Arabic  digits  and  the  following  special 
cha  rac  t  e r s : 

•>  t  A  •  -  .  / 

The  first  character*  however*  must  Qfli  be  a  digit.  :se  of 
the  slash  <"/")  Is  strongly  discouraged  for  reasons  which 
will  soon  become  apparent.  The  ease  of  the  alphabetic 
characters  Is  Insignificant  since  the  system  forces  thee  all 
t  o  uooer  c  i  se .  T  hus 

GEORGE  Harry  *y_f1le  Tour. File  filel 
are  all  legal  file  names*  while 

<bad_f  1  le^naise  >  naugh t  y_f  1  le !  666 


are  not* 
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a.z.  mtmiiti 

F,IKO«  associates  the  name  of  •  file  with  It*  content* 
through  the  u*e  of  ’director les* *  which  themselves  are  noth- 
Ino  more  than  ordinary  file*  that  PRIMOS  treat*  specially* 
A  directory  contains  a  number  of  ’entries’*  each  of  which 
hi'.'ds  the  name  of  a  file  plus  other  Information  (which  we 
wilt  qet  to  later)*  and  the  location  on  the  storage  volume 
of  the  actual  content#  of  the  file*  Cach  file  with  a 
corresponding  entry  In  a  given  directory  Is  said  to  ’reside 
within*  that  directory*  and  that  directory  Is  said  to 
•conta In’  * ol 1  file*  for  which  It  holds  an  entry*  Now  there 
Is  nothing  that  prevents  us  from  having  within  a  directory  a 
file  that  1#  1t*elf  a  directory*  This  phenomenon  Is  known 
as  ’nestlm*  of  directories  and  may  be  carried  out  to  any 
depth*  olvlna  rise  to  «  hierarchical  structure: 


files 


I  I 

file?  dir? 


It  should  be  noted  that  while  the  name*  of  all  file*  within 
a  given  directory  must  he  unique  among  them*elve*«  It  Is 
oerfectly  legal  to  have*  In  separate  directories*  two  dif¬ 
ferent  files  w<:.  the  same  name*  So*  In  the  e*ample  above* 
file*  that  resides  within  dir*  Is  distinctly  separate  fro* 
f 1 1 c a  thftt  resides  within  d1r2* 


At  the  topmost  level  of  the  hierarchy  Is  the  master  file 
directory  <mfd>»  which  always  begins  at  a  ftxed  location  on 
a  given  storage  volume*  In  addition  to  several  entries 
reaulred  by  the  system*  the  MFD  contains  any  other  direc¬ 
tories  and/or  ordinary  files  that  an  Installation  may  see 
fit  to  aalntain*  (Normally*  a  directory  Is  established 
within  the  mfo  for  cach  Individual  user  of  the  system*  Each 
such  directory  Is  known  as  a  user  file  directory  or  UFO*) 

Now  that  we  have  a  structure  containing  multiple  nested 
directories  and  potentially  duplicate  file  names*  the 
problem  arises  as  to  how  a  specific  file*  say  the  one  named 
"files’  In  the  exaaple*  1*  referenced;  or  wor*e*  how  one 
file  named  "files"  Is  referenced  distinctly  fro*  another  by 
the  sane  name  but  In  a  different  directory*  Pathnames* 
which  we  take  up  1 1.  the  next  section*  are  the  solution. 


fc 


f 


i 


'*  1 
* 

i 

i 


Georgia  Institute  of  Technology 


COBOL  workbench 


Appendix  8 


THE  PRIHOS  FILE  SYSTEM 


Page  263- 


•  •3*  £  A  IBM  ABU 

A  pathname  Is  a  syntax  for  unlourly  specifying  any  file 
contained  within  the  file  system*  Out  before  we  can  no  any 
further*  a  couole  of  details  should  be  brought  to  light* 
When  it  user  logs  In  to  PRIHOS*  he  Is  automot  leally  ’at¬ 
tached*  To  n  specific  directory  whose  name  Is  usually  the 
same  as  his  login  name*  This  directory  Is  said  to  be  his 
♦current*  or  ‘default*  directory  and  has  a  special  sin- 
nlflcance  In  the  interpretation  of  pathnames*  There  Is  a 
way  to  wall  around  within  the  file  system*  changing  the 
current  directory*  but  we  won*t  go  Int*1  that  here* 


As  we  said*  a  pathname  allows  you  to  unlouely  specify  any 
file  anywhere  In  the  hierarchy  by  describing  a  path  to  the 
file  from  some  known  point*  Two  such  known  points  arc  the 
current  directory  and  the  MFD*  A  pathname*  then*  consists 
of  a  number  of  directory  names*  separated  by  slashes  ("/*• 
recall  our  orevlous  admonition)  and  ending  with  the  name  of 
the  desired  file.  If  the  pathname  starts  with  a  slash*  the 
oath  startr  In  the  *FD)  otherwise*  It  starts  in  the  current 
directory*  A  staple  file  name  that  contains  no  slashes 
refers  to  a  file  within  the  current  directory;  a  pathname 
consisting  only  of  a  single  slash  refers  to  the  MFD  Itself) 
and  the  emoty  pathname  refers  to  the  current  directory* 
Thus*  the  pathnames 


/btn/cd 
aydlr/f  1  le 
/ 

lempty  string) 

refer  to  a  file  named  *ed"  within  a  directory  named  "pin* 
which  Is  contained  In  the  MFD)  a  file  named  "file"  within  a 
directory  named  "mydlr"  which  sprouts  from  the  current 
directory*  wherever  that  may  be*  the  MFD)  and  the  current 
directory*  respectively* 


eaftiEcuM 

Use*-*  have  the  option*  If  they  so  desire*  to  protect  their 
files  from  unwonted  perusal  or  alteration  by  other  user?* 
Two  mechanisms  are  Involved  In  providing  this  featu' 
First*  with  each  directory  Is  associated  an  "owner"  and 
"password"*  The  owner  of  a  directory  Is*  by  default*  thv 
user  who  created  It*  though  this  may  be  changed*  When  a 
directory  becomes  a  user’s  current  directory*  either  of  two 
conditions  nay  orevall)  the  user  may  oe  declared  ’owner*  of 
the  directory  If  his  login  name  matches  that  of  the  direc¬ 
tory’s  creator*  or  falling  this*  he  Is  declared  a  *non- 
owner**  The  password  comes  Into  play  In  this  latter  ease* 
The  owner  of  a  directory  may  require  that  any  non-owner  who 
wishes  to  make  It  his  current  directory  must  first  specify  a 
password*  If  he  Is  able  to  do  this*  then  he  Is  attached  to 
the  directory  as  a  non-owner)  otherwise*  he  Is  not  allowed 
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to  attach  to  It* 

Once  attached  to  a  directory*  either  at  owner  or  non-owner* 
the  second  protection  mechanism  cowet  Into  play*  At  port  of 
the  "other  Information"  tnat  we  mentioned  In  the  directory 
entry  for  a  file*  the  system  keeps  two  tett  of  ’protection 
key***  one  that  applies  to  the  owner  of  the  directory*  and 
the  other*  to  ncn-owners.  These  keys*  which  may  be  changed 
on  a  per-flle  basis  by  the  d1rectory*t  owner*  control  the 
kinds  of  things  that  can  be  done  to  a  file*  There  are  three 
ooer<*ttons  that  may  be  Individually  allowed  or  denied  to 
both  owner  and  non-ownertt  reading*  writing  and  truncating 
(drletlna).  If  a  user  has  read  permission  for  a  file*  he 
way  read  the  contents  of  It  but  may  In  no  way  alter  them* 
If  write  permission  Is  granted*  then  the  file  may  be  written 
upon  (possibly  overwriting  existing  Information  or  extending 
the  file)*  but  nothing  may  be  read  from  It*  If  truncate 
permission  Is  granted*  the  file  may  be  shortened  to  any 
lenoth  or  even  removed  completely*  but  Its  contents  may 
neither  be  read  nor  written. 


8.5.  SUMMARY 

There  ore  *nny  more  feature*  and  subtleties  In  the  PRJMOS 
file  system  that  both  enhance  Itt  power  and  usefulness*  as 
well  an  ade  to  Its  awkwardness.  Those  things  we  have  talked 
about  here.  though*  seem  to  be  the  most  Important  tor  a 
general  understanding.  For  further  details  on  these  other 
feitures  <>nd  on  the  Implementation  of  the  file  system*  you 
might  wont  to  consult  the  tUj£tCl?I?£g  Qu.ld**  FUt  Mqnifl ement 
&Xil£2*  published  at  PORillO  by  Prime  Computer*  Inc.* 
Fram1n«7ha»»  Pass. 
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COBOL.wbc 

APPENDIX  9 
COBOL. wbc 


This  appendix  contains  sons  of  the  preliminary  work  towards 
deflnlno  rOBOL.wbc  that  has  been  accomplished.  The  first 
section  provides  some  Insight  Into  the  frequency  of  the  use 
of  various  features  of  COBOL*  while  the  second  section  shows 
the  actual  dlscrepanc  les  discovered  between  some  of  these 
features. 


9.1.  uaifit  fl£  tarn  EUIM8E1 

A  Study  of  the  Usage  of  COBOL  Features 

The  llstlnn  below  provides  the  frequency  (static)  of  use  of 
reserveo  words  discovered  In  a  file  containing  about  20*000 
lines  of  code  from  iruy  progress. 


G 

0 

0 

27 

0 

20 

0 

0 

0 

0 

0 

0 


ACCEPT 

0 

CF 

ACCESS 

12 

CM 

ACTUAL 

0 

character 

ADO 

136 

characters 

ADDRESS 

0 

CLOCK-UNITS 

ADVANCING 

G 

CLOSE 

AFTER 

0 

mum 

ALL 

2 

CODE 

alphabetic 

1 

CODE-SET 

ALSO 

0 

COLLATING 

alter 

0 

COLUMN 

alternate 

G 

COMMA 

AN 

2 

COMMON 

AND 

36 

COMMUNICATION 

apply 

C 

COMP 

ARE 

22 

COMPUTATIONAL 

AREA 

0 

COMPUTE 

ARC  *S 

4 

CONFIGURATION 

ASCENDING 

0 

CONTAINS 

ASSIGN 

9  1 

CONTROL 

AT 

59 

CONTROLS 

AUTHOR 

9 

COPY 

BEFORE 

0 

CORR 

BEGINNING 

0 

CORRESPONDING 

BLANK 

0 

COUNT 

BLOCK 

20 

CURRENCY 

BOTTOM 

c 

DATA 

BY 

269 

OA  Tf 

CALL 

59 

OATE-COMPILfD 

CANCEL 

0 

oate-written 

CO 

0 

DAY 
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Page 

mO 

CM 

OE 

0 

GO 

1243 

OEDUG-CONTCNTS 

0 

GREATER 

148 

OCSUG-ITEH 

0 

GROUP 

0 

debug-line 

0 

HEADING 

0 

DEBUG-NAME 

0 

HIGH-VALUE 

0 

ocrug-suo-i 

0 

HIGH-VALUES 

27 

DE8UG-SUB-2 

0 

I  -0 

3 

DrpuG-SUB-  ' 

0 

I-0-C0NTR0L 

0 

DEBUGGING 

0 

IDENTIFICATION 

13 

DECIMAL-POINT 

0 

IF 

88b 

DECLARATIVES 

0 

IN 

0 

DELETC 

0 

INDEX 

3 

DEL  I M I  T £Q 

0 

INDEXED 

8? 

DELIMITER 

c 

INDICATE 

0 

0C°£  NO ! NG 

1R 

INI T I  A*. 

0 

OESCCNOlNG 

0 

INITI.  E 

0 

DESTINATION 

0 

INPUT 

14 

detail 

0 

INPUT-OUTPUT 

13 

DISABLE 

0 

INSPECT 

2 

display 

577 

INSTALLATION 

11 

DIVIDE 

0 

INTO 

2 

DIVISION 

56 

INVALID 

39 

OQVN 

1  ft 

IS 

337 

DUPLICATES 

0 

JUST 

0 

DYNAMIC 

0 

JUSTIFIED 

0 

rc  i 

0 

KEY 

61 

ELSE 

72(1 

KEYS 

0 

Emi 

0 

LABEL 

41 

ENABLE 

0 

LAST 

1 

END 

5* 

LEADING 

1 

CNO-OF-PAGC 

0 

LEFT 

0 

ENDING 

0 

LCMGTH 

0 

ENTER 

0 

LESS 

37 

ENVIRONMENT 

1* 

LIMIT 

0 

EOP 

0 

LIMITS 

0 

EQUAL 

;  57 

LINAGE 

0 

ERROR 

• 

1 

LINAGE-COUNTER 

0 

ESI 

0 

LINE 

0 

EVERT 

0 

LINE-COUNTER 

0 

EXAMINE 

0 

LINES 

0 

exception 

3 

LINKAGE 

8 

EXIT 

193 

LOCK 

0 

EXTEND 

0 

LOV-VALUC 

7 

PO 

A  1 

LOW-VALUES 

9 

PILE 

22 

MEMORY 

0 

file-control 

13 

MERGE 

0 

FtLE-LIHIT 

0 

MESSAGE 

0 

file-limits 

0 

MOOE 

22 

filler 

1012 

MODULES 

.  2 

FINAL 

0 

MOVE 

336* 

F  PST 

0 

multiple 

0 

footing 

0 

multiply 

5 

FOR 

6 

NATIVE 

0 

FROM 

113 

NEGATIVE 

Q 

generate 

0 

NEXT 

583 

GIVING 

42 

NO 

4 
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«v» 

NOT  * 

1  53 

REPORT 

0 

NOTE 

0 

REPORTING 

0 

NUMBER 

0 

RTPORTS 

b 

NUMERIC 

2 

RERUN 

0 

08JCCT-C00MPUTER 

0 

RESERVE 

0 

Q8o  -T-PROGRAH 

0 

RESET 

0 

OCC?  .S 

1  0  A 

RETURN 

0 

OF 

19 

RCVERSEO 

0 

OFF 

0 

REWIND 

0 

OMITTED 

1 

REWRITE 

10 

ON 

23 

RF 

0 

OPEN 

21 

RH 

0 

optional 

0 

RIGHT 

0 

OR 

162 

ROUNDED 

7 

ORGANIZATION 

3 

RUN 

26 

OUTPUT 

6 

SA 

0 

OV 

0 

SAME 

0 

overflow 

0 

SO 

0 

PAGE 

0 

SEARCH 

13 

PAGE-COUNTER 

0 

SECTION 

84 

PERFORM 

668 

SECURITY 

0 

PF 

0 

SEEK 

0 

PH 

0 

SEGMENT 

0 

PIC 

4833 

SEGMENT-LIMIT 

0 

PICTURE 

9 

SELECT 

41 

PLUS 

0 

SEND 

0 

POINTER 

0 

SENTENCE 

583 

POSITION- 

0 

SEPARATE 

0 

POSITIVE 

0 

SEQUENCE 

0 

PRINTING 

0 

SCOUENCED 

0 

PROCEDURE 

14 

SEQUENTIAL 

4 

PROCEDURES 

0 

SET 

262 

PROCEED 

0 

SIGN 

0 

PROCESSING 

0 

SIZE 

0 

PROGRAM 

28 

SORT 

0 

PROGRAM- ID 

14 

SORT-MERGE 

0 

QUEUE 

0 

SOURCE 

0 

QUOTE 

0 

SOURCE-COMPUTER 

5 

QUOTES 

0 

SPACE 

61 

RANDOM 

7 

SPACES 

222 

RO 

C 

SPECIAL-NAMES 

0 

read 

56 

STANDARD 

41 

RECEIVE 

0 

STANDARD-1 

0 

RECORD 

61 

START 

8 

RECOROS 

43 

STATUS 

0 

REOEFINES 

147 

STOP 

26 

REEL 

0 

STRING 

0 

REFERENCES 

0 

SU6-GUEUE-1 

0 

relative 

0 

SU9-QUEUE-? 

0 

RELEASE 

0 

SUB-QUEUE-3 

0 

REMAINDER 

0 

SUBTRACT 

40 

REMARKS 

3 

SUM 

0 

removal 

0 

SUPPRESS 

0 

RENAMES 

0 

SYMBOLIC 

0 

RENAMING 

0 

SYNC 

23 

REPLACING 

0 

SYNCHRONIZED 

9 
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TABLE 

2 

UNSTRING 

0 

TALLY 

7 

UNTIL 

86 

TALLYING 

2 

UP 

95 

TAPE 

0 

UPON 

0 

TERMINAL 

Q 

USAGE 

6 

TERMINATE 

0 

USE 

0 

TEXT 

0 

USING 

65 

THAN 

177 

VALUE 

172* 

THEN 

0 

VALUES 

0 

THROUGH 

2 

VARYING 

66 

THRU 

*56 

WHEN 

11 

TIME 

G 

WITH 

0 

TIMES 

SO 

WORDS 

0 

TO 

5091 

WORKING-STORAGE 

19 

TOP 

0 

WRITE 

21 

TRAILING 

1 

ZERO 

*86 

TYPE 

0 

2ER0ES 

26 

UNIT 

0 

2  EROS 

SR 

9.2.  Mfltmmt  & £  cam  tuiuau 

Soaa  Eiaaples  of  the 
Coaparlson  of  COBOL  Feature*  Offered  by 
the  To  COBOL  Standard*  POP-li  COBOL*  and  PRIME  COBOL 


The  following  are  eicerps  fro*  a  were  co*olete  study  of  the 
difference*  found  In  varlou*  feature*  of  COBOL  on  several 
■schlncs. 


£££ik£I  Identlfler-l  t  f  R  QM  aneeonlc -name  3 
AH££1  Identlfler-l  (  BAlt  I  BAX  I  Hit  > 

1>  7*  COBOL 

a)  Oat*  1*  tr#n*ferred  according  to  the  rule*  of 
MOVE. 

»)  “newon 1 c-naee  *u*t  be  specified  In  the  SPECIAL* 
NAMES  paragraph. 

c)  If  the  FROM  phrase  1*  not  given*  the  device  that 
the  1nplc*enter  specifies  a*  standard  1»  used* 

d)  If  the  site  of  the  data  being  transferred  1* 
Identical  to  the  site  of  Identlfler-l*  the  data  Is 
transferred  and  stored  In  Identlfler-l* 
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c>  If  the  size  of  ldcntlfler-1  Is  toss  than  the  size 
of  the  data  belnq  transferred*  the  left-most 
characters  of  the  data  being  transferred  are 
stored  In  Ident 1 f 1er-l «  left-justified*  characters 
to  the  right  are  Ignored. 

f)  If  the  size  of  tdentlfler-t  Is  greater  than  the 
size  of  the  data  oelng  transferred*  the  data  Is 
stored  t ef t - J us t 1 f led  and  additional  data  is 
requested.  For  subsequent  data  transfers*  the 
size  of  ldentlfler-1  Is  taken  to  be  equal  to  the 
as  yet  unfilled  oortlon  of  It. 


g)  DATE  Is  Inpllcltty  described  as  an  elementary  data 
Ite*  with  PICTURE  of  9C6)V;  It  contains  year  of 
the  century*  *onih  of  the  year*  and  day  of  the 
year  In  that  order. 


h)  OAT  Is  Inpllcltty  described  as  an  elementary  data 
Ite*  with  PICTURE  of  9 < 5 > V l  It  contains  year  of 
the  century  and  the  day  of  the  year  numbered  front 
1  to  366* 


1>  Time  It  tmollcltly  described  as  an  elementary  data 
1t«*  with  PICTURE  of  9(B)Vl  the  value  represents* 
In  a  24-hour  system*  the  nu«ber  of  elapsed  hours* 
minutes*  seconds*  and  hundredths  of  seconds  after 
oldntght  In  that  order  fro*  left  to  right. 


2>  PDP-11 


a)  As  In  7a  COBOL . 

b)  As  In  74  COBOL. 

c>  If  the  PROP  phrase  Is  not  given*  the  data  Is 
transferred  fro*  the  user’s  terminal. 

d»  As  In  74  COBOL. 

e>  As  In  74  COBOL. 

f)  If  the  size  of  IdentlHer-l  Is  greater  tha,n  the 
size  of  the  data  being  transferred*  this  data  Is 
stored  left-justified  and  the  remaining  space  pad* 
ded  with  blanks. 

q)  As  In  74  COBOL. 

h>  This  1*  identical  to  DATE. 

1)  as  In  74  COBOL*  but  the  positions  for  the  hun¬ 
dredths  of  a  second  are  fitted  with  zeroes. 
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a)  Characters  are  moved  without  change. 
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t> >  As  In  74  COBOL. 

c>  If  the  FROM  phrase  Is  not  given.  the  data  Is 
transferred  fro*  the  user’s  terminal. 

d>  As  In  74  COOOL. 

e )  4*  In  74  C080L. 

f>  If  the  sill  of  ldentlfler-1  Is  less  than  the  slee 
of  the  data  being  transferred,  the  left-most 
characters  of  the  data  oelng  transferee  are  stored 
In  ldcntlfler-1*  left-justified,  and  the  regaining 
space  Is  filled  with  blanks. 

gl  As  In  74  cn^OL. 

h)  As  In  74  CO-^L. 

1l  TINE  Is  Implicitly  described  as  an  elementary  data 
Item  with  PICTURE  of  9<6>Vl  It  contains  hours, 
minutes,  and  seconds  In  that  order. 
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i*ril 


ififi 


(  ldentlfler-1  |  literal-!  )  C  *  C  Identlfler-Z  | 
literal-2  )  3  ...  ifi  Identifier-*  C  BOUNDED  3  C  . 
Identt  f ler-n  C  ROUNDED  3  3  ...  Cl  ON  $U£  ERROR 
Imperat ive-statement  3 


C  ldentlfler-1  |  llteral-l  )  .  I  ldentlfler-2  j» 
literal-2  3  l  »  f  ldentlfler-3  }  literal -3  )  3  ... 

Identlfler-o  C  RQUNPES  3  C  »  Identl  f  ler-n  C 
RfifiNfififi  3  3  9  ..  C  1  ON  Hit  CRBQR  Imperative-statement 
3 


ififi  <  fifii&fifififififiilifi  I  COR*  3  Identifier-!  T£  irfentlf 1er-2  C 
ifiUfifikfi  3  C  t  ON  Hifi  £&&£&  Imperative-statement  3 


74  COBOL 


a> 


In  formats  1  and  2.  each  Identifier  must  refer  to 
an  elementary  numeric  Item,  eweept  that  In  format 
2  each  Identifier  following  the  word  GIVING  must 
refer  to  either  an  elementary  numeric  Item  or  an 
elementary  numeric  edited  Item!  In  format  3.  each 
Identifier  must  refer  to  a  group  Item. 
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Each  literal  must  be  a  numeric  literal* 


The  composite 
digits* 


operands 


exceed- 


In  format  l«  values  of  operands  precedlno  the  word 
TO  are  added  together*  then  the  sum  Is  added  to 
the  current  value  of  Identifter-n  storing  the 
result  Imeeolstely  Into  1  dent  1 f 1er-m«  and  repeat¬ 
ing  this  process  respectively  for  each  operand 
following  the  woro  TO* 

In  format  2*  the  values  of  the  ooerands  preceding 
the  word  GIVING  are  added  together*  then  the  sum 
Is  stored  as  the  new  value  of  each  Ident If 1er-m» 
Identlf 1er-n*  •*•«  the  resultant-identifiers* 


In  format  3* 
added  to  and  * 
ldentltler-2* 
Identtf 1er-l 
if  <11  they  ar 
and  have  t 
quantifiers  up 
and  Identifier 
elementary  nun 


the  data  Items  In  ldentltler-1  are 
tored  In  corresponding  data  Items  In 
A  pair  of  data  Items*  one  from 
and  one  from  Identifier-2  correspond 
e  not  designated  by  the  word  FILLER 
he  tame  data-namc  and  the  sane 
to*  but  not  Including*  ldentlfler-1 
-2*  <21  both  data  Items  are 
eric  data  Items* 


The  compiler  Insures  that 
carried  so  as  not  to  lose  any 
during  execution* 


enough  places  are 
significant  digits 


Size  error  condition: 

1)  A  size  error  exists  when*  after  execu¬ 
tion  of  the  adoltlon  and  subsequent 
decimal  point  alignment*  the  Integer 
portion  of  the  absolute  value  of  the 
result  Is  too  large  to  fit  Into  the 
receiving  Item*  This  does  not  apply  to 
Intermediate  results*  If  rounding  Is 
specified*  It  occurs  prior  to  the  checR 
for  the  size  error. 

If  a  size  error  occurs  and  the  SIZE 
ERROR  phrase  Is  specified*  the  values  of 
the  receiving  Items  affected  by  size 
errors  are  not  altered*  After  execution 
of  the  statement*  the  Imperative 
statement  of  the  SIZE  ERROR  clause  Is 
executed  fit  Is  executed  only  once  per 
statement  execution). 

If  a  size  error  occurs  and  the  SIZE 
ERROR  phrase  Is  not  specified*  the 
values  of  the  Items  affected  by  size 
errors  are  unpredictable* 
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1>  If  truncation  ha*  occurred  and  the  ROUNDED  option 
i*  specified*  then  if  the  most  significant  digit 
of  the  truncated  part  is  five  or  more*  a  one  is 
added  to  the  absolute  value  of  the  result* 

?)  PDP-11 

a)  As  in  74  COBOL* 

o)  is  in  7*  COBOL* 

c )  l>  the  size  of  the  Intermediate  result  field  is 
greater  than  IB*  the  excess  high-  >r  digits  are 
truncated* 

d)  As  in  74  COBOL • 

e)  As  in  74  COBOL* 

f)  As  in  74  COBOL*  but  «  pair  of  data  Items 

correspond  if  they  are  elementary  numeric  data 
items*  and  they  have  the  same  name* 

g>  A  maximum  of  1H  digits  are  carried*  thus  anything 
over  this  is  lost* 

h>  Size  error  condition: 

1>  As  in  74  COBOL. 

11>  As  In  74  COBOL. 

Hi)  If  a  size  error  occurs  and  the  SIZE  ERROR 
phrase  is  not  specified*  the  high-order 
digits  are  truncated* 

1)  As  in  74  COBOL. 

3)  PRIME 

ado  { ident 1 f 1er-l  |  literal-1  )  t*  t  Identifier-2  | 
literal-?  )  3  ...  T£  Identifier-m  C  ftoyNDED  3  C  ;  Oh 
§XiStm  ERRpR  imoerat ive-statement  3 

A££  (  identifier-1  |  literal-1  )  (  *  {  identifier-2  ( 

literal-2  )  )  C  *  l  identifier-3  |  literal-3  3  ... 

Q^V^Cy  identifier-*  I  ROUNDED  3  C  ON  SIZE 
Imperative-statement  3 

a)  as  In  74  COBOL*  but  cannot  have  multiple  receiving 
identifiers  or  ADO  CORRESPONDING. 

b>  As  in  74  COBOL. 

c)  As  In  74  COBOL. 

** 

d>  As  in  74  COBOL*  but  can  only  have  one  Identifier 
after  the  word  10. 
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At  In  74  COBOL*  but  can  only  have  on  Identifier 
offer  the  word  GIVING. 

The  CORRESPONDING  feature  1*  not  available. 


As  In  74  C000L ♦ 


As  In  74  COBOL. 


tmm 

COMPUTE  Identlt  1er-l  C  ROUNDED  3  C  *  Identifier-?  C  RQUNDCQ 
3  3  ...  =  ar1thmet1c-e*pre*s1on  C  \  ON  $t?C  ERROR 

Imperative-statement  3 


1)  74  COBOL 


a)  Identlf 1er-l«  1  dent  1 f ter-2*  ••«  must  be  elementary 
numeric  Items  or  clemcntory  nuaerlc  edited  Item*. 

b)  This  statement  allows  the  jter  to  combine  arith¬ 
metic  operations  without  the  restrictions  on  com¬ 
posite  of  operands  and/or  receiving  data  Items  la* 
posed  by  the  statements  A00*  SUBTRACT*  NUIT|PLV« 
and  DIVIDE. 

2 >  POP-11 

a)  As  In  74  COBOL. 

b)  the  lengths  of  the  Integer  and  decimal  components 
of  an  Intermediate  result  are  .determined  by  an  al¬ 
gorithm  which  uses  the  lengths  of  the  operands  In 
determining  these  values.  The  sum  of  the  lengths 
of  the  Integer  and  decimal  components  must  be  less 
than  18. 

3 )  PRIME 

£flg£Ulil  Identlfler-l  C  RQUNDEp  s  orlthmetlc-expresslon  C  * 

ON  Sl?£  Imperative-statement  3 

a)  As  In  74  COBOL*  but  can  only  have  one  Identifier 
before  the  equal  si in. 

b>  The  composite  of  operands  must  not  contain  more 
than  18  decimal  digits.  «, 
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